Smart Disorganized (incoming)

July 04, 2015

Dave Winer

Let's create an open source Medium clone

To weekend JavaScript hackers..

I would love to help create an open source Medium clone, so you don't see things like this. An open source program putting user advisories in a silo. This is wrong. These docs should be put in a place that has some chance of longevity.

I've done half of the work. Check out MyWord Editor. It's also on GitHub.

Then check out medium.js. Looks pretty good.

Can you figure out how to merge the two? I want to make the text area part of MyWord Editor to use medium.js, and do it in a nice way. Once we have that, I can take it from there.

I put a fair amount of time trying to get this to work, but failed to get a reasonable subset of medium.js to work in a standalone app. Once we have this connection, we'll be most of the way there. Not only will we have an editor, but the content will be stored in an S3 bucket. If you want to run the back-end, that's open source too.

For the right person this is probably a two-session job. A good chance to work together to help the web.

PS: This is a perfect project for Independence Day weekend!

PPS: Here's an example of a page rendered by MyWord Editor. Click the hamburger icon for a list of other examples.

July 04, 2015 01:55 PM

July 03, 2015

Lambda the Ultimate

Don Syme receives a medal for F#

Don Syme receives the Royal Academy of Engineering's Silver Medal for his work on F#. The citation reads:


F# is known for being a clear and more concise language that interoperates well with other systems, and is used in applications as diverse asanalysing the UK energy market to tackling money laundering. It allows programmers to write code with fewer bugs than other languages, so users can get their programme delivered to market both rapidly and accurately. Used by major enterprises in the UK and worldwide, F# is both cross-platform and open source, and includes innovative features such as unit-of-measure inference, asynchronous programming and type providers, which have in turn influenced later editions of C# and other industry languages.

Congratulations!

July 03, 2015 07:16 PM

Dave Winer

Too much linear thinking in news

Ken Doctor asks if there is a business model for news lurking in the midst of Apple, Twitter, Facebook et al. As all such pieces that begin this way, he concludes, maybe, but he's not sure how.

The correct answer is no, as long as the tech industry controls news distribution, nothing good is going to happen for journalism.

The linear way to think

Many journalism thinkers approach these questions linearly.

  1. Here's what we do now.

  2. Some new reality has taken hold.

  3. Change what we do to continue to do what we used to do.

I liken it to picking up a box and moving it from one place to another. When you're done it's still a box. But the box must become a sled. Or a merry go round. When it's done it won't seem like a box.

Change makes things different

Look at the components that make up our online lives today.

  1. Wikipedia wasn't a linear change from Britannica, for example because it didn't preserve Britannica's business model.

  2. Tinder is radically different from the singles ads that used to run in local newspapers.

  3. Spotify is fundamentally different from FM radio. So much so that Apple's new music service is re-introducing the idea of FM radio. It'll be interesting to see if we're interested in having our music programmed for us, since we've been able to do the programming for the last 15 years.

I think it's safe to extrapolate that news will work radically differently too.

Note: The title of this section is meant to be funny.

Two cents about Circa

I've wanted to comment on Circa since they suspended operation.

  1. I think they were on to something. Starting topics, and then adding stories to each topic as the news comes in. A story isn't something that's published once and done, it's more of a process. It isn't just a linear re-shaping of what we did in the print era. Maybe now that they've suspended operations, one of their developers could do a YouTube demo of how the editorial tools worked? I'm sure I would find it interesting.

  2. If the editorial tools were good and reasonably easy to use, I wish they would have made them the product, and hired journalists, as needed, to mold an editorial product created by the users of the product. Find the good stuff and surface it. That's how news must scale to meet the Web.

  3. Circa resisted joining the open web. I think that was a fundamental mistake. They needed to find more readers, to do that they had to find the people who distribute links. Linkblogging is a real thing, and there are people who are good at it. But if there's no URL for each story, you can't linkblog it. So they didn't grow fast enough. I think this is almost mathematical. No one, going forward, should try this. Each story must have a way to get to it through a Web address. Even if Facebook et al own the distribution system.

How to

So if linear isn't the right way, what is?

Circa had the right approach. They asked: How can we create an incredibly fantastic new way of doing news that wasn't even remotely possible before the Web? Then, follow your nose. Build a prototype as quickly as possible, and use it. Iterate. Use it some more. Etc.

And that reminds me...

Use it!

Use it. Use it. Use it. Repeat that 10000 times. You need to use it. Or it won't work.

Why is Twitter failing where Facebook is thriving? Zuck was teasing them when he said they needed more stock to keep Wall St from interfering. Imho that's not great advice. Better: Twitter would be a formidable competitor if they had leadership that understood their own product. Zuck uses Facebook confidently and skillfully. There's the difference. Leadership of users, because the top guy is a user.

There's never been a long-term thriving tech company that wasn't run by a user.

If you're not excited by news, get out of the way

If you don't love the product, move aside and make way for someone who does.

Think about it this way, if you wanted to run a brewery, but you didn't love beer, how great would the product be? Not too great. Or if you ran a ski area, but didn't like to ski. How could you judge whether an idea is good or not? Take a poll? Run a focus group? That only works (somewhat) for established businesses, not revolutionaries, disrupters, innovators. If you want to make a big difference you have to have a big ego and a big vision. There's something inside you that has to come out. And you won't take no for an answer.

It's true in tech, but it's also true in news. Maybe that never occurred to anyone that news, at one time, was itself new. It's now so old and set in its ways that even the slightest bit of movement, even if it's just an experiment, is thought of as progress.

But now news is new, again. The question isn't how to remain what we always were, rather it's how to become what we now can be.

July 03, 2015 01:09 PM

July 02, 2015

Dave Winer

riverToTweets.js

This is pretty technical stuff, but it's indicative of the kind of work we're doing with River4.

https://github.com/scripting/riverToTweets

It's a publishing system. I don't think there's anything else like it in the open source world.

Something we should be connecting on with journalists. I could easily teach smart users how to set up a river of news.

They would instantly be more powerful than anyone else in news!

July 02, 2015 03:54 PM

Mark Bernstein

In The World

A surprising number of people live as in a cloister.

At Wikipedia, I’ve been trying to get a peace agreement on Gamergate. The facts on the ground are now clear. It’s time to end the conflict which has raged over nine months, a dozen Wikipedia pages, more than a million words of debate, and dozens of blocks and bans and

  • Gamergate wanted to use Wikipedia to launder its reputation while using other parts of Wikipedia to smear its enemies.
  • Wikipedia has pretty much decided to say “no, you can’t do that.”

It took too long, it cost too much, the resolution was too uncertain, but here we are. Even if Wikipedia again lost its mind and gave Gamergate what it wants, the outcry of a watchful would soon restore reason. There’s no need for 50,000 words of wrangling and five banned zombies every month; it's just vexation and waste of effort.

The Gamergate attack on Wikipedia has failed. What could they do now? They could make their way in the world. If they did – if Gamergate actually accomplished stuff, if (for example) they published insightful studies of ethics in games – then newspapers would report it, scholars would write about it, and Wikipedia would eventually cover it. That’s their best move, the only productive move I can see that’s left on their board.

So, why does Gamergate stick to the current operation, which pairs sliming women in the software industry with a flood of complaints intended to wear down the referee Wikipedia admins?

The explanation, apparently, is that Gamergate fans don’t think it’s possible to actually participate in the world of ideas, the world outside fandom and Wikipedia. This also explains their peculiar outrage at me: when I took the case against Wikipedia to you and then to the world, I was using my super-powers to cheat. One editor actually wrote that I “accidentally set the Internet on fire.” In their view, I’m a comic-book character who somehow summons up lightning bolts in the middle of a basketball game to help my team win, and that’s just unfair.

We might dismiss this with a nod to Gamergate HQ in Mom’s Basement, but it’s not just Gamergate. I keep bumping into grad students, for example, who regard living writers as if they were all inaccessible rock stars. Yes, there are some writers who won’t talk to you, but most will. The same is true for scholars: not only will most professors take your phone calls or give you interviews, asking them will make their day. “You can be the most famous Chemist in the world,” Frank Westheimer used to say, “and you’re still not going to be on Johnny Carson.”

Linda says this is a class issue, that the knowledge of these open doors is a secret of privilege. She is not wrong: class is part of the story.

My own initial theory was that it’s literally a matter of experience. When I was in grad school, Mom used to drive me nuts with suggestions that I stop sending stuff to tiny computer magazines and start aiming for places like The New Yorker. I thought then she was clueless, but before she was Mom she’d worked for McCalls and for Hearst, and 25 W 45th St was just another address. Lots of stuff seems impossible until you do it, and the typical Gamergater is probably a bit younger than I am.

Some of it’s a matter of education, of knowing (at least in theory) how things work. In grade school, one teacher – maybe Helen Doughty in 2nd grade – required everyone to send a fan letter to a contemporary writer. “Contemporary” was quite a word for second graders! Somewhere I’ve got a nice form letter, signed by Ted Geisel/Dr. Seuss. (The Cat In The Hat remains a really interesting book when you think about it.)

I was texting yesterday with one of my fellow software artisans about the software economy and all our woe. He pointed it that it’s not just software. His friend the famous novelists isn’t making big money. His friend the rock star isn’t making much money, either. One of the big surprises in The Way The World Works was seeing Amanda Palmer, not that long ago, Twittering for couches in cities where she was touring. The same thing happens fictionally in Wonderland, Stacey D’Erasmo’s nifty and thoughtful novel of a rock tour. Even for rock stars, I slept last night in a good hotel ain’t necessarily so. It’s not just us: it’s the world. Knowing that matters. (More on the software economy coming soon.)

It’s one thing to renounce the world and choose to live quietly by Walden. It’s another to renounce the world and then to stew endlessly in your powerlessness, and then to avenge your renunciation with talk page diatribes and mean little exposés and incessant gossip about Gamergate’s arbitrary victims in chat rooms and image boards.

July 02, 2015 02:56 PM

July 01, 2015

Dave Winer

How to fix my iMac internal fusion drive?

  1. I have a 5K Retina iMac. Its internal drive is an SSD.

  2. It's not working. Let me explain.

  3. I booted off an external drive.

  4. When I look at the drive in the Disk Utility, there's no option to erase it.

  5. When I look at the Partition tab, everything is grayed out.

  6. When I click on Verify Disk, it says everything is good.

  7. When I repair the disk it says it's all good.

  8. The disk does not show up on the desktop.

  9. Software cannot see it.

  10. I want to format the drive. How?

The fix is in!

Update: Problem solved in the Facebook thread.

Bonus: A video of me fixing the problem, in case you have the same thing wrong with your Mac fusion drive.

July 01, 2015 09:40 PM

Giles Bowkett

Actually, No, Stuff Used To Work

I see this sentiment on Twitter all the time:


The link's to a story about the surprising incompetence of Apple's new music streaming service.


But the first computational device, the abacus, was invented around 2400BC. And we've been storing programs on hardware since 1948. So, either software is not still in its infancy, or it's been in that infancy for a very long time. If anything, software seems to get more infantile with every passing generation.

In fact, even as recently as a few decades ago, software companies used to have things called "QA departments" whose whole reason for existing was to make sure that everything worked all the time.

Software is not in its infancy. Software is in a period of decadence, characterized both by unprecedented power and wealth, and by staggeringly low standards. In its past, software put a man on the moon. The most magnificent computers of that time were weaker than the computers in an actual toaster today. It wasn't the hardware, it wasn't the complexity of the software. It was the QA department, and the seriousness of the mission.

by Giles Bowkett (noreply@blogger.com) at July 01, 2015 06:17 PM

June 30, 2015

Fog Creek

3 Reasons to Switch to FogBugz Ocelot

FogBugz Ocelot is the latest version of FogBugz. It’s our fastest and most powerful version yet. It comes with an updated UI, and bags of new functionality that make Ocelot that best way to use FogBugz. Here are three reasons why you should make the switch.

agile-filters@2x

1. A More Agile FogBugz

One important part of working on a new version of FogBugz was making sure it was the best tool it could be for different ways of working. You’ve long been able to work and do Agile with FogBugz, but with FogBugz Ocelot, and the new Iteration Planner, we’ve made Agile a first-class citizen in FogBugz. Iteration Planner allows you to graphically group cases, divide the scope of your sprint into groups and monitor progress toward each of your goals. And, it’s just a click away with the new Agile menu.

2. No More Context Switching

Another important consideration was how best to keep up to date with activity in FogBugz. A lot of our customers live in FogBugz for their working days. Yet, you had to switch to email to keep up with notifications about activity. Now that’s no longer the case. We’ve added In-app Notifications, Activity Feeds and Digest Emails, to help you keep up to date with what’s going on, without all the email.

3. More Easily Organize and Manage Your Work

We also wanted to make it easier for you to organize and manage your work. So we’ve added Project and Filter Menu groups so that you can combine projects for easier filtering, as well as organize your filters more effectively.

Learn more about the new, fast and feature-filled FogBugz Ocelot and try it for yourself. Here’s further info for:

by Gareth Wilson at June 30, 2015 10:45 AM

June 29, 2015

Reinventing Business

The Best Summary of Teal Organizations So Far

Here is a slide deck that gives quite a thorough introduction to Teal organizations, including insights that I've also spontaneously considered in my own research. I think I've seen (and perhaps linked to) an earlier version of this deck but if so it has gotten much, much better.

I feel like I've been waiting my whole life for this kind of organization. Bits and pieces of these ideas have presented themselves but they've always seemed ridiculous in the context of industrial-age management thinking. I want to either work with such an organization or, more probably, create one.

The creation of such organizations is where I might be able to make a contribution, and I'll be giving a presentation called Creating Trust Organizations at the upcoming OSCON in Portland. I've been putting a lot of effort into this presentation and hope that I'll be able to give it many times, whenever I travel.

by noreply@blogger.com (Bruce Eckel) at June 29, 2015 05:12 PM

Fog Creek

dev.life – Interview with Cassidy Williams

In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

Today’s guest is Cassidy Williams, Software Engineer & Developer Evangelist at Venmo. She’s a proud proponent of young women pursuing careers in Software Engineering and other areas of science, technology, engineering and mathematics (STEM). Towards this end she’s worked on AdvisHer, Microsoft’s Big Dream documentary and Hacker Fund, receiving recognition for her efforts by being named in Glamour Magazine’s ‘35 Women Under 35 Who Are Changing the Tech Industry‘ and in the Innotribe Power Women in FinTech Index.


Cassidy Williams
Location: New York City, NY, US
Current Role: Software Engineer & Developer Evangelist at Venmo

How did you get into software development?

We had a family computer that we all shared from when I was very little (the earliest I remember playing on it was my 6th birthday), but I didn’t have my own computer until college. I started out with HTML and CSS! When I was first learning, I didn’t know what code was. Nobody in my family did, either. But when I was in 8th grade, I heard a neighbor say, “check out my website!” while I was talking home from school. When I got home, I literally just started looking up how to make one. I started with a WYSIWYG editor, and then I realized that if you knew how to code, you could do a lot more. So I started messing with it from there! So I was self-taught in Web Development, but I also then graduated with my Computer Science degree.

mechKeyboard

Tell us a little about your current role

My role is awesome. On the Software Engineering side, I work on the code that keeps Venmo up and running. I’m currently on the Web Team, working on some cool new technologies (like React and ES6). On the Developer Evangelism side, I speak at hackathons, conferences, and meetups, and I represent Venmo to the developer community. I currently have an awesome intern, Terri, and she and I are working on cool projects like a podcast of her internship, some volunteering events, and some women in tech meetups. I never have a “typical” day, because I touch so many different things at work! I’m currently working on learning Unity and game development. It’s interesting because it’s a totally different way of approaching coding, but that also means that it’s challenging as I’m thinking about problems in a different way.

When are you at your happiest whilst coding?

When I find a tough bug or I have a tough problem, and I solve it. It’s the most gratifying feeling ever.

bigNerd

What is your dev environment?

At work and on some projects, I use OSX and Vim as my editor and Git as my Version Control. My personal laptop is a Windows machine, where I use pretty much every editor out there, depending on the project (Eclipse, Visual Studio, Aptana, Sublime, Vim, Unity, etc)! I also have this sick mechanical keyboard that I customized with some Vim stuff, and it’s got Cherry MX Brown keys. I just use random headphones at work, but when I’m coding at home, I use Audio-Technicas. If I’m focusing, I listen to classical and instrumental music. Currently listening to the Dark Knight soundtrack and some Igor Stravinsky ballets.

What are your favorite books or resources about development?

I love the JavaScript Weekly and HTML5 Weekly newsletters, they always push out some really interesting articles. Books, I like the Big Nerd Ranch books, The Pragmatic Programmer, and The Little Schemer!

myo

What technologies are you currently trying out?

I want to try messing with a Thalmic Labs Myo. I also just got myself some LittleBits to try playing with.

When not coding, what do you like to do?

I love playing music, Minecraft, drawing, and eating.

What advice would you give to a younger version of yourself starting out in development?

Don’t waste your time on technologies that you don’t enjoy. It’s so much more fun to code on things that you want to code on!

 

Thanks to Cassidy for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

Recent dev.life Interviews

Paul Jones
Paul M. Jones
Michael Fogus
Michael Fogus
Casey Muratori
Casey Muratori
Tomomi
Tomomi Imura

by Gareth Wilson at June 29, 2015 11:27 AM

John Udell

Why is automating simple tasks so hard?

It seemed like such a simple thing: Make charts and tables and share them with the team.

If I had to do that only once in a while, it would be straightforward to do it in Google Apps. But I need to do this daily, with fresh data. I have a Python script that fetches the data and makes the charts and tables. I envisioned two ways to reuse that script:

[ Here are 6 skills a solid IT generalist should master, no matter where your life in IT leads. | Get the latest practical data center info and news with Paul Venezia's Deep End blog. ]

Option #1: Just upload the charts and tables to Google Drive.

To read this article in full or to leave a comment, please click here

by Jon Udell at June 29, 2015 10:00 AM

June 28, 2015

Dave Winer

To make a long story short

We need a better way to do discourse on the net.

See the longer version.

June 28, 2015 09:45 PM

Mark Bernstein

Rainbow Dinner

Hooray for the Supreme Court, which (surprisingly) decided not to make things worse this week.

  • Pickled rhubarb with ginger and star anise ❧ pickled carrots with dill ❧ onion dip
  • Focaccia with ricotta, goat cheese, mozzarella, and lots of caramelized onion
  • Sandwiches of grilled salmon, crusted in aioli and parmesan
    • home-made potato break rolls with election-day seeds
    • burnt onion and cilantro salsa
    • grilled peach, red pepper, and chipotle salsa
  • salad
  • clafoutis

June 28, 2015 03:15 PM

Dave Winer

It's not left vs right

Yesterday's post was intended to be humorous. I don't doubt that algorithms could figure out what most people say on Facebook, and do our speechifying for us. The point behind the humor is this: No issues are so black and white that your template for discourse will spit out a useful statement just by skimming a story.

This dumbing-down of discourse is not just present in social networks, but it's also in the news. The NYT says the victories for "the left" now present opportunities to pivot for the right. Well, the victories of this last week are not for the right or the left, and some of it wasn't a victory at all.

  1. In what way are nine people slaughtered in a church in Charleston a victory for the left? Sometimes you can go too far in tallying these things up as scores for one side or another. It was not a victory for anyone, it was a tragedy, for everyone -- everyone who is not a sociopath.

  2. Government shouldn't be in the marriage business. That would have been my decision if I were on the Supreme Court. The net-effect would be the same as what came out of the court last week. I don't see how my opinion about this is left? It's actually fairly conservative.

  3. But I haven't forgotten that our society and those of all other western countries, not too long ago, didn't allow homosexuality to even exist in public, much less ratify their right to marry. It's still shocking to see two men holding hands walking down the street in the city. I don't mind being shocked, I actually like it. It's a reminder that this was a choice we made, to open our minds, to change. The fact that we can do this, so quickly, makes me optimistic about other changes, other comforts we have to give up.

  4. For example, we have to accept that it's okay not to procreate. It's actually a good thing for the human species if there were fewer of us. Let's have a holiday for people who choose not to be fathers or mothers.

  5. Or that people over a certain age are still alive and part of the world, and have aspirations, knowledge, experience, rights and want to make a contribution, too. How is that left vs right? Everyone ages.

Maybe it's time to give up that there is such a thing as "the left" or "the right". That each of us has the right and obligation to think and decide for ourselves. And for crying out loud, just because someone disagrees with you on one issue that doesn't mean they're bad, or that they might not agree with you on others. Remember how much we all have changed in the last few years.

We still have a long way to go, and framing things as a never ending battle between two non-existent forces isn't going to help us. It would be nice if social networks could help us evolve out of this mess. I still think the potential is there. But first we have to have the will to change.

June 28, 2015 02:39 PM

ZZ85

Emscripten Experimentation Experience

At one point Emscripten was the hottest thing in the JS world and I decided to try it. I started writing about the experience in this post but the procrastinator in me didn’t finish it. Fortunately, the content went into these slides and gave a talk about it in Feb earlier this year. The slides should cover most of the content here but feel free to read on if you have the time.

http://slides.com/zz85/emscripten-struggles

I talked about a struggle with Emscripten, on how the going wasn’t easy especially for someone who wasn’t familiar with C. Still various times the idea of using emscripten was incepted (eg. this twitter thread). Among the stuff that I wanted to try porting was GLSL Optimizer. I gave it my first shot and wasn’t successful with that. GLSLOptimizer was also written because HLSL2GLSLfork (for unity3d) generated GLSL code that could be optimized.

Emscripten probably wasn’t the most complex piece of software (besides it have probably been used successfully with millions lines of code) but why did I failed again and again? In retrospective there were a few reasons

1) these projects weren’t trivial
2) my Emscripten environment was probably messed up
3) I wasn’t familiar with C or C++ world (even though I’ve programmed in c and objc)
4) I wasn’t familiar with the build systems automake/make/cmake/premake, its ecosystems and workflows

These factors made it like learning to jump before crawling. So I’d put these on my backburner. Once in a while I try getting my hands dirty again, till I hit another brick-wall. Repeat.

One day I was reading some GLSL code online and I mistaken it as HLSL. Thinking about how to convert it to GLSL, I end up attempting emscripten-ization again. HLSL2GLSL project came to mind but this time found out a new hlsl-to-glsl project, which turns out to be a newer and simpler shader project.

This project uses premake, so I learn about it. I had progress building stuff, and despite some errors, I could fix. I realized that there were also forks of that project (eg. being used by the witness), and I tried those code too. I also figure that premake doesn’t have to be used. I could run a simple compilation command.

/usr/lib/emsdk_portable/emscripten/1.29.0/emcc src/*.cpp -o hello.html -s EXPORTED_FUNCTIONS=”[‘_parseHLSL’]” –bind -O3

There were other pitfalls and lessons learn’t along the way. Especially with how the JS and emscripten are bridged. There were different approaches: CCall could be used, or using marcos, eval and bindings but one have to be careful the datatypes gets converted correctly through the bridge too.

So yeah, I got emscripten working for the HLSL converter demo and source code

That gave me some experience and confidence boost, and I went on to make glsl-optimizer work. Glsl-optimizer has more code and slightly more complexted, but I follow the previous approach of rolling my own build scripts and and had it work too. See Demo and Code.

There’s one thing I haven’t manage to solve, that is getting data corruption issues using link-time optimizations, so it’d cool if anyone managed to fix that, that would bring down the generated JS even further.

And there’s has been recent update with these projects – Jaume (aka thespite) has attempted integrating GLSL optimizer in his really cool Chrome WebGL Shader Editor extension.

One of the ideas still lingering in my mind would be porting a good sounding midi / wavetable synthesizer like fluidsynth to JS. Stay tuned!

by Zz85 at June 28, 2015 03:49 AM

June 27, 2015

Axis of Eval

A trivial implementation of Reactive Demand Programming

I wrote a trivial implementation of RDP in JavaScript to help me understand how it works.

It's called bucky-rdp (about 200 lines of heavily commented code).

It currently supports Sirea's bconst, bpipe, and bfmap.

Here's an example:

// Create some behaviors for transforming numbers.
var bDouble = rdp.bFMap(function(val) { return val * 2; });
var bMinusOne = rdp.bFMap(function(val) { return val - 1; });

// Create a pipeline behavior of the two behaviors
var myBehavior = rdp.bPipe(bDouble, bMinusOne);

// Apply an inactive input signal to the pipeline behavior
var sigIn = rdp.makeSignal();
var sigOut = rdp.apply(myBehavior, sigIn);

// Change the input signal value and watch the output signal change
sigIn.setValue(2);
console.log(sigOut.getValue()); // Prints 3
sigIn.setValue(4);
console.log(sigOut.getValue()); // Prints 7
sigIn.deactivate();

(This post refers to v1.0.1)

by Manuel Simoni (noreply@blogger.com) at June 27, 2015 11:33 PM

Dave Winer

Facebook is about news, in a weird way

Each bit of news potentially fires up a moral parade, where people recite prepared speeches.

Often the speeches begin explaining how what someone said is like this other thing, then basically recites a canned story about that thing.

You could give each story a number, and just type the number. The computer (Facebook) could then get the text and insert it into the comment for you. Discourse could happen much faster.

Eventually Facebook could predict what you'll say and just say it for you. Like the self-driving cars Google is making. You'd sign onto Facebook and see in your notification drop down menu "You have commented on Betsy Guernsey's post."

You could read it if you like, but eventually you will know that Facebook correctly stated your opinion.

June 27, 2015 09:21 PM

Tim Ferriss

TF-StitcherButton

IMG_3790

“In order for art to imitate life, you have to have a life.”
– Whitney Cummings

“I promise: if you just tell the truth and get your heart broken as a comedian, you will have a house.”
– Whitney Cummings

This episode how to turn pain and struggle into amazing creative projects.

Whitney Cummings (@whitneycummings) is a Los Angeles-based comedian, actor, writer and producer.

She is executive producer and, along with Michael Patrick King, co-creator of the Emmy nominated CBS comedy 2 Broke Girls, which was recently picked up for a fifth season.

Whitney also wrote, produced and starred in Whitney, which aired on NBC from 2011 to 2013.

She has headlined with comics including Sarah Silverman, Louis C.K., Amy Schumer, Aziz Ansari, and others.

Her first one-hour stand up special, Money Shot, premiered on Comedy Central in 2010 and was nominated for an American Comedy Award. Her second stand-up special, Whitney Cummings: I Love You, debuted on Comedy Central in 2014 and she is shooting a third hour for HBO this August, which is set to air in 2016.

TF-ItunesButtonTF-StitcherButton

Want to hear another podcast with a world-class comedian? — Listen to my conversation with Bryan Callen. In it, we discuss eating corgis (yes, the dogs) and improving creativity (stream below or right-click here to download):


This podcast is brought to you by MeUndiesHave you ever wanted to be as powerful as a mullet-wearing ninja from the 1980’s, or as sleek as a black panther in the Amazon? Of course you have, and that’s where MeUndies comes in. I’ve spent the last 2-3 weeks wearing underwear from these guys 24/7, and they are the most comfortable and colorful underwear I’ve ever owned. Their materials are 2x softer than cotton, as evaluated using the Kawabata method. Check out MeUndies.com/Tim to see my current faves, some of which are awesomely ridiculous.

This episode is also sponsored by OnnitI have used Onnit products for years. If you look in my kitchen or in my garage you will find Alpha BRAIN, chewable melatonin (for resetting my clock while traveling), kettlebells, maces, battle ropes, and steel clubs. It sounds like a torture chamber, and it basically is. A torture chamber for self-improvement! Ah, the lovely pain. To see a list of my favorite pills, potions, and heavy tools, click here.

QUESTION(S) OF THE DAY: What really offends you, and how might you analyze the reasons to improve yourself? Please share in the comments.

Scroll below for links and show notes…

Enjoy!

Selected Links from the Episode

Huffington Post | Salon | Slate | Psychology Today | Jezebel | The Frisky

  • Watch Neil Gaiman’s commencement speech, Make Good Art
  • Learn more about the Friar’s Roast
  • Enjoy standup from a few of Whitney’s recommended comics:

Sebastian Maniscalco | Tig Notaro | Jerrod Carmichael
Natasha Leggero | Chris D’Elia | Neal Brennan

Website | Facebook | Twitter | Instagram

Show Notes

  • Whitney Cummings’s tattoo stories: leadership, emotional intelligence, and managing trauma triggers [6:33]
  • Strategies for handling the weakness of impatience (aka “the impatient dick syndrome”) [19:33]
  • Has emotional intelligence work removed the magic of her success? [25:53]
  • The story of when Whitney realized her workaholic nature was killing her [34:13]
  • The emotional habits which helped Whitney to achieve so much at such a young age [37:03]
  • On managing the challenges of immediate gratification [40:33]
  • The process behind Whitney’s best writing [42:53]
  • Deconstructing Whitney’s most recommended work [55:13]
  • Defining “blue” comedy and exploring why it’s a strange title [45:48]
  • On roasts, insult comedy, adulation from fans, and differing comedic styles [1:08:08]
  • Whitney Cummings’s training for taking someone from beginner to stand-up comic in 8 weeks [1:23:33]
  • On equine therapy [1:57:23]
  • Most gifted books [2:04:18]
  • When you think of the word “successful,” who’s the first person to come to mind? [2:12:43]
  • If you could put a billboard up anywhere you wanted, what would be on it, and where would it be? [2:20:48]
  • Advice to her 20-year old self [2:25:18]

People Mentioned

by Ian Robinson at June 27, 2015 04:56 AM

June 25, 2015

Mark Bernstein

Fog Creek

Killing Off Wasabi – Part 1

FogBugz v8.13.104 was released at the end of May 2015, with little fuss and no fanfare. And why would it? The release notes list just a couple of bug fixes and minor changes. But under the hood, it was a huge release. For the first time since FogBugz’ creation some 15 years ago, it contained 0 lines of VBScript or Wasabi code. The ‘End‘ of an era.

For those of you that don’t know, Wasabi was our own in-house .NET compiler. In this post, I’m going give you the background of Wasabi, including why we created it and what it enabled us to do, before giving you the inside scoop on why we’ve now killed it off. In a follow-up post, we’ll talk about some parts of Wasabi that we’ll be open-sourcing.

A Time-Saving Beginning

FogBugz was created as an internal tool to help track bugs in our first product, CityDesk, and support our consultancy work. It was written in VBScript and was Windows only. But from its first public release, customers asked for a Linux version. We didn’t want to throw away what was already a large codebase and start from scratch on a new cross-platform version. So we hired our first summer intern to create Thistle. Thistle was a compiler, written in Java, that translated a limited subset of VBScript into PHP. It consisted of a tokenizer, a simple parser, and a finite-state machine based PHP generator. For anything that could not be expressed in Thistle, there was a special syntax to embed PHP code directly in the ASP. It wasn’t pretty, but without requiring a total rewrite of FogBugz, it meant we could support both Windows and Unix.

Thistle received a couple of small updates over the next few years, such as adding the ability to generate ASP, so that we could insert code coverage logging information into the generated code.

FogBasic: Further Down the Rabbit Hole

Then around 2005, we leaped wholeheartedly down the rabbit hole. Thistle became FogBasic and we had visions of creating a new language that overcame many of the issues with writing ASP. This decision wasn’t without its critics, but we really wanted to make it so that as many programmer errors as possible were found at compile time instead of runtime. So we added numerous features and extensions to the language, like updating the lexer to more rigorously match the language, parsing a full abstract syntax tree, and adding type inference.

In the summer of 2006, FogBasic became known as Wasabi, and we continued to make improvements. By this point, almost all of the new code in FogBugz 6.0 used one or more Wasabi features. Wasabi could generate ASP, PHP, and client-side JavaScript. It supported Picture Functions, reduced the amount of duplicate code we needed to write by generating client-side code and had support for things like Fragment Caching and Memoization enabled through compile-time code generators. Wasabi 3, released to the public alongside FogBugz 7 in 2009, had modern .NET-style features like Interfaces, Enums, Try/Catch, and base classes. FogBugz 7 ran on Mono or Microsoft .NET instead of PHP or Classic ASP, generated by Wasabi 3’s new CodeDOM-based code generator.

Maintenance Problems

As time wore on, our technical debt finally began to come due. Compilers like Wasabi and their associated runtime libraries are highly complex pieces of software. We hadn’t open-sourced it, so this meant any investment had to be done by us at the expense of our main revenue-generating products. While we were busy working on exciting new things, Wasabi stagnated. It was a huge dependency that required a full-time developer — not cheap for a company of our size. It occasionally barfed on a piece of code that was completely reasonable to humans. It was slow to compile. Visual Studio wasn’t able to easily edit or attach a debugger to FogBugz. Just documenting it was a chore: FogBugz’ Lead Developer at the time, Aaron Maenpaa, wrote ‘Wasabi – The ??? parts‘, a book released internally in 2011 that attempted to document Wasabi’s features and many quirks.

Life also got in the way. The people who wrote the original Wasabi compiler moved on for one reason or another. Some married partners who lived elsewhere; others went over to work on other products from Fog Creek. Of course, we couldn’t just hire someone with prior knowledge of it. Well, except for me, as I had worked on it back in 2008, then left, but was re-hired four years later! But otherwise, all new hires had an extensive period of learning Wasabi, regardless of their previous experience.

What’s more, we weren’t living in a vacuum. Programming languages were of course improving outside of Fog Creek. Indeed, a lot of the features Wasabi added were things that C# 2.0 delivered out of the box, and there have been three more major versions of C# since then. Developers began to feel like their brilliant ideas were being constrained by the limitations of our little Wasabi universe.

So, alongside the work on FogBugz Ocelot, the latest version of FogBugz, we decided to begin removing Wasabi from FogBugz. There had been other proposals to do so in the past. When Wasabi 3 was started, one of the proposals was to do a one-shot compile to Python, but this was rejected in favor of the .NET backend. In 2011, Ted Unangst proposed “Project Soy Sauce”, a combination of .NET Reflector and Perl scripts to turn the Wasabi binary output into nearly-readable C# source code. This time, we finally succeeded, because of Roslyn, the newly open-sourced .NET Compiler Platform.

Pulling the Plug

So with the decision made, work began, which included:

  • Step 1: change the output of Wasabi from a .NET assembly to C#. The old .NET code generator was based on System.CodeDom, an earlier Microsoft technology that generated valid C# and VB.NET code from a lowest-common-denominator abstract syntax tree. We added its C# output to a new project in the FogBugz solution with a precompilation step that invoked Wasabi with the requisite command-line arguments.
  • Step 2: Switch from CodeDOM to Roslyn. It took 2 weeks to reach functional parity between CodeDomGenerator and RoslynGenerator, at which point we excised the former from Wasabi.
  • Step 3: Improve the output of RoslynGenerator. So many little edge cases were improved here, including ‘!=’, do/while, hex literals, logical and arithmetic negation, constants, switch statements, for loops with simple bounds, else if, lambdas, initializers, extraneous casts and parentheses, string literals, Wasabi Union types, and optional parameters.
  • Step 4: Kill Wasabi. Commit the C# files that Wasabi output, and remove Wasabi and the .was files from the tip of the FogBugz repository. We also had to rewrite a little language file generator that had been generating Wasabi to instead generate C#.

Lessons Learned

Having our own programming language helped us grow FogBugz, a multi-decade project, from VBScript to PHP and JavaScript, and finally switch over to the brave new world of .NET. Wasabi made a lot of sense a decade ago, when we had a blooming code base we wanted to transplant into new ecosystems. It made sense in 2008 to switch the backend to .NET, which was easier to maintain and a faster platform on which to run FogBugz. Since we were consolidating into a single backend, it might have made sense at the time to do a one-time compile using a hand-written C# generator. Once Roslyn was released, it made even more sense to finish switching completely over to C#.

Building an in-house compiler rarely makes sense. It is much more economical to lean heavily on other people’s work and use standard, open technology. You must be prepared to not only create your own universe but to then nurture it long-term. We weren’t ignorant of this when the project began, but it’s much easier to switch languages at the beginning of a project than halfway through. A homegrown compiler might make sense when trying to port to a new platform, which Wasabi helped us do several times.

In the next post, we’ll dive into the new Roslyn-based code generator in Wasabi that we’re open-sourcing. We hope that by doing so, anyone who is considering generating C# code programmatically will have guideposts to using Roslyn as their code generator.

by Jacob Krall at June 25, 2015 01:45 PM

Dave Winer

Dropbox could be king of the one-page app

In 2013 when we were getting our browser-based outliner ready, Les Orchard, a longtime reader of this blog, and contributor to our community (he wrote the initial S3 glue for Frontier, a huge gift), suggested we look at using Dropbox as our storage system.

I was already a serious Dropbox user, and loved how it virtualized my file system. Using Dropbox meant I could go anywhere, with a laptop, and have access to my full work environment. This was part of the dream of using networks since I started using them in the 70s. Dropbox was a big piece of the puzzle.

But Les had shown me how Dropbox could be even more.

Fargo, my Dropbox-based writing environment

We hooked our outliner up to their file system, and shipped it. That's Fargo.

I'm using Fargo to write this. Scripting News, my blog, is a Fargo site.

Later, I put a content management system in Fargo, so you could now publish a website without any extra server software. It still amazes me that this experiment worked.

Now I read articles that Dropbox is facing increased competition from Microsoft and Google. They need something extra, something different from the Office suites both companies offer. Imho it should be of the web, using the most modern approach to development, the single-page JavaScript app.

Developers, developers, developers

I think independent developers have the key to giving them a competitive edge.

There's a universe of possible one-page apps and a vast sea of developer creativity to tap into. They just have to help create the market, a little more than they already have.

June 25, 2015 01:21 PM

June 24, 2015

Dave Winer

PagePark and OPML

The other day I released riverBrowser, a JavaScript toolkit, for browser apps, that renders JSONP files produced by River4.

I also released outlineBrowser. It does for JSON outlines what riverBrowser does for rivers. The two are a pair, because outlines can appear in rivers, you need both to display a river. I wanted to separate them, however, because outlines can appear outside of rivers.

With outlineBrowser, I could add a feature to PagePark, my easy to use Node.js web server. Now, if you put an OPML file in any folder that's served by PagePark, renders it through a user-specified template and it's then passed through outlineBrowser. The result is quite functional if not yet beautiful. It also handles includes, which is fairly difficult to do in JavaScript, with all the async michegas, but I figured out how to do it, and it works.

I have tons of content in this format. Frontier, OPML Editor and Fargo outlines are all stored in OPML. It's the standard format for RSS subscription lists. There's a lot of OPML out there. And PagePark should be able to do a nice job with all of it.

Slowly and surely it's coming together.

PS: Here's a short demo of an outline in a river.

June 24, 2015 11:45 PM

Mark Bernstein

SummerFest

There’s still time to head over to SummerFest: the 2015 Festival of Artisanal Software For Writers.

Save 25% on some of the best artisanal tools for writers for a few days more. Tinderbox, DEVONthink, Scrivener, Nisus, Aeon Timeline, Bookends, Take Control Books.

Also: MicahJoel writes about using Tinderbox and Scrivener.

SummerFest

June 24, 2015 04:21 PM

The Chaco Meridian (2nd edition)

Newly revised and expanded edition of Lekson’s daring and irreverent manifesto which proposes a historical framework for the American Southwest. The traditional view of the Southwest before Spain has been scrupulous to avoid history: as Lekson says, “no states north of Mexico” has long been dogma. Lekson argues that Chaco (900-1100) was a state (or, more properly, an altepetl) with princes and palaces, that it first moved north to Aztec for a generation, and then jumped South all the way to Paquime/Casas Grandes. In the second edition, he extends the trip further, proposing that after Paquime fell, its elites relocated due South once more to establish Culiacán.

Strikingly, Aztec is almost exactly due north of Chaco, and Paquime and Culiacán are due south. They're the biggest and strangest sites of their time. The alignment is embarrassing, but it’s real, and it turns out that ancient travelers could in fact have surveyed the route this accurately.

There’s lots of interesting news in the fifteen years since the first edition. We now know what those weird, distinctive Chaco cylinder pots were for: they were for drinking cacao! We know because Crown and Hurst grabbed some fragments fresh out of the trash heap, ground up a thin layer of the interior, and ran the extract through a mass spec: theobromine — the stuff in chocolate! So those dudes at Bonito drank hot chocolate that was harvested somewhere in south-central Mexico and hand-carried, across mountains and deserts, for their ritual enjoyment. (This stuff must have cost far more than the most costly wine.)

Whether or not Paquime is Aztec relocated (or, perhaps, the faction of Chaco that couldn’t live with the guys going to Aztec one day more), it's now clear that the Southwest knew about, and participated in, Mesoamerica. Lekson is surely right, too, in thinking that they knew about Cahokia. Even if you have to carry every scrap of your food, and even without horses or carts, you can walk hundred of miles. Sacagawea wasn’t the first native American to take a long walk.

Lekson is an irreverent and radically informal writer, and among the great stylists of contemporary historical writing.

June 24, 2015 04:17 PM

Dave Winer

A spilled cup of coffee

This morning I spilled a whole cup of coffee, a big one, on my work desk. The one with all my computers and wires and disks.

I immediately went into action, throwing everything of value off the desk as quickly as I could, including both my cell phones, an iPhone and a Nexus 6.

I then cleaned up the mess, thankfully none of the equipment appears to be damaged, and I went and read for a while. To try to calm my nerves.

Then, I got a phone call. My iPad was ringing. Someone was calling my iPhone, it said. But where is the iPhone???

I still can't find it. Oy.

Eventually the battery will die, and when that happens, how will I find it. And I have this great Apple Watch that's useless without the iPhone.

Oy. Oy. Oy.

PS: Shortly after publishing this, I found it. It was in the pile of rags I used to mop up the mess. Whew.

PPS: There are little dried drops of coffee on my monitors.

June 24, 2015 03:45 PM

Key concept of the open web: Working Together

This morning there were two excellent essays from leaders of the open web, David Weinberger, one of the Cluetrain guys, and a longtime friend and colleague, and Dries Buyteart, founder of Drupal and software entrepreneur. Both are beautifully written and honest appraisals of why the open web is losing to the silos.

Both are optimistic and doing the best they can to help the open web be the powerhouse we all thought it was a few years ago. And the one we still hope it can be.

I would like to elaborate.

Working together

The promise of the open web was and is this: collaboration.

But it's always been a promise, and many have acted in their own self-interest only, and forgot that in order for the open web to thrive we must feed it.

They have taken out of the web without putting back.

Use it or lose it. That applies to muscles as much as it does to the open web.

The rule of working together

Working together means this: If someone else has a good-enough way to do something, rather than reinvent what they do, incorporate what they do into what you do.

There's a flipside. If I have to reinvent your whole product just to get a feature, you're not part of the open web.

An example of working together

When I was getting started writing server software in JavaScript, I had a thought not unlike the thought that probably happens at many silo companies. The process went like this: I'm going to need an RSS feed parser. A friend of mine, Dan MacTough, had created one and released it as open source. I found it confusing. So I decided that this was important enough that I should have "my own" feed parser.

However, before I started writing my own, I sat myself down and asked if it would be better for everyone if I created yet another feed parser, or if I used Dan's. I decided, no matter how much work it would be to learn his way of doing it, even if it took longer to use his than to create my own (which also would have been more fun) I would be doing good for the net if I just used his. So I did. No regrets. I still don't understand how it works internally, but I've helped build a network of software, instead of creating another software island.

And in practical terms, an island is just as isolating as a silo.

Working together means APIs

One of the things that's wrong in today's software is people tend to leave off the APIs. Or, if they're VC-funded, they're likely to have the APIs in the beginning, to help attract users and developers, but as they want to become profitable, they restrict the APIs. So much so that many developers no longer trust corporate APIs. Me too. I much prefer open cloneable APIs, with more than one implementer. That makes it impossible for a platform to screw its users and developers, because if they do, no problem -- I'll just use another one.

One company that's generating a huge unicorn-level market cap is Slack. Hats off to Stewart Butterfield, the founder, and his team, who seem to have managed to create something that's both part of the open web and enormously profitable for investors. Please study this Ms and Mr Venture Capital. Note that strangling your community isn't the only way to get rich.

Working together means using open software

This is the hardest one to explain, because users seem to think they have no power re the open web and no responsibility. But the toys you love, Facebook, Instagram, SnapChat, etc, couldn't have existed if they couldn't have siphoned power from the open web. If you think the toys are getting more similar and perhaps a bit boring, this is why: there hasn't been enough investment in open web tech in the last few years. Not enough know-how for the merchandisers to commercialize.

When a developer ships a tool that doesn't lock you in, it's worth using it, even if there is a "free" one that works a little better or has a nicer design. Because the open one, the one that lets you leave when you want to, preserves freedom, and the others consume it.

It's really rare in today's world when a normal person has such power to affect the outcome, but every software developer needs users. Even just a few. Without users, how can you tune your software up to fit people who think differently from yourself. And creating new software, at this point in the evolution of this art, is still relatively easy and inexpensive. So a few users can be very powerful, but you have to choose to be. That choice is itself an act of creativity, and working-together.

How silos can help

Make it easy for people to post to your site and to sites they, the users, control.

For example, Facebook posts are notoriously difficult to find after they've scrolled too far down the timeline, or aren't favored by the algorithm.

Yes, Facebook let's you download your archive, but what if we could echo our writing to a personal blog, as we're writing or updating? One that would provide us or our children and grandchildren a place to look up our writing years or decades from now?

It's likely this would increase use of Facebook, because people would post stuff there to make notes to themselves and future generations. It certainly wouldn't hurt. And since Facebook has profited so enormously from the open work of others, it would be a mitzvah, something good they can do to help repay the generosity of those who came before them.

Summary

I'm illustrating the idea of working together by pointing to Dries' and David's pieces at the beginning of this post, and then elaborating on the ideas they present. I could have left the links off and pretended I was the only person thinking this way. But that wouldn't have been very powerful, and it wouldn't have helped the open web.

When you have a choice, instead of re-inventing someone else's work, use it.

That's the simplest and most powerful way to help the open web.

June 24, 2015 02:33 PM

Fog Creek

N Ways to be a Better Developer – Interview with Lorna Mitchell

.little {font-size: 75%}
N Ways to be a Better Developer – Interview with Lorna Mitchell

Looking for audio only? Listen on

In this interview with Lorna Mitchell, author of ‘N Ways To Be A Better Developer’, we cover some great tips on being a happier and more productive programmer. Including how to communicate with management, the importance of mentoring and learning new languages, improving your time management and dealing with complexity. For more on these topics, Lorna writes regularly on her blog.

Content and Timings

  • Introduction (0:00)
  • About Lorna (0:31)
  • Learn to Speak Manager (1:46)
  • Learning New Programming Languages (2:52)
  • Dealing with Complexity (3:57)
  • Being a Role Model (5:46)
  • Confessional Debugging (8:50)
  • Reading Widely (11:04)

Transcript

Introduction

Derrick:
Lorna Mitchell is Principal Developer at Siftware and a long-time web development Consultant and Trainer. She’s the author of the books ‘PHP Master’ and ‘PHP Web Services’, writes regularly on her blog about software development topics. She’s also a regular conference speaker, and it was a keynote talk that formed the basis of her book, ’N Ways To Be a Better Developer’.

Lorna, thank you so much for taking the time to join us. Do you have a bit to share about yourself?

About Lorna

Lorna:
I am essentially a web developer and these days I do a bit of consultancy, some writing, and, of course, my day job where I am a team lead. Because I’m part-time in my day job I get to keep that cross-section and get the opportunity to spend time on open-source, at conferences, and also writing.

Derrick:
What made you want to write the book ’N Ways To Be a Better Developer’?

Lorna:
It’s from a keynote talk and I had co-presented that talk with my friend, Ivo Jansch. He and I had worked together and then given this talk together. We were giving the talk again, a new iteration, at PHP Northwest. The talk was on Saturday. I think it was about Monday, just five days before, where we said, “Yeah, we should definitely ship this as a book.”

By the magic of Leanpub and a really quick turnaround from a designer that we found for our cover we did ship it. Obviously I had all the rehearsals, all my notes, all the topics just in my mind, and we’re both already published authors. Although the book has more content in it now, and we have continued to add to it. At the time it was purely that we were just so excited about our topics that we wanted to write it down and let it scale up a bit more than just the people in the room.

Learning something new… reminds us why we are Engineers

Learn to Speak Manager

Derrick:
You recommend that developers, “learn to speak manager”. What do you mean by that and why is it important?

Lorna:
I mentioned I co-presented with Ivo. Ivo, when he taught me to speak manager, because he was my CTO, and I was just a developer in the team. I was having that classic problem I have seen so many more times since of a developer who can really see a great solution to something and can’t express to the manager why it’s important. You can end up feeling like there’s conflict there. Like you’re actually against each other.

We’re all on the same page. The managers want to deliver things and the developers want to deliver things but the developers want to deliver with the right tools and the managers want to deliver within the right budgets. Sometimes it can be a little bit in conflict. If I learn to speak manager… Almost stand in your manager’s shoes and understand that person’s priorities, motivations and what’s important to them. Then try and frame your solution in a way that makes it clear to them that you’re all on the same team.

At every point in your career someone is behind you… when you’ve only taken two steps, someone has only taken one

Learning New Programming Languages

Derrick:
You suggest developers constantly learn new languages. Why do you think this is beneficial?

Lorna:
Learning your first programming language is like pushing something heavy up a hill. You just feel so small and so lost. There’s so much to know and you don’t even know what half the words mean so you can’t look them up. When you learn your second programming language it’s just like pushing something about your own size up a hill. The third language and the fourth language, you cross-pollinate all those ideas.

The skills are really transferable. No matter how many programming languages you know, a new language or a new framework makes you feel really small again. Continuing to learn is good for us, and remembering that we’re quite small is, I think, sometimes good for us. I think developers… learning something new and having what I call the light bulb moment with a new project reminds us why we are engineers. Sometimes I just need a bit of new technology to remind me why I do this, when things have got hard going in my other projects.

Dealing with Complexity

Derrick:
Sort of the opposite of small is software projects that are complex. Things like that have tasks that often take longer than we expect. How can developers get better at managing their time?

Lorna:
I often think it’s not a problem about time management. It’s a problem about estimations. Developers look at a feature and they think, “Yeah I could do that, couple of days.” In fact, that feature that was going to take a couple of days will always ship in six days. It’s a function of not necessarily seeing the work to fit it into its whole. It’s not necessarily remembering the time that it will take to prepare that feature for deployment, or to make it work on everybody’s development platforms.

We just see that we’re interested in it and we don’t always remember the rest of the story. Developers are also, almost universally, optimists. We just think, “Oh yeah, we can do that.” We have to keep believing that we can do it or we just wouldn’t. We tend to, in general, we underestimate.

What I have found is that if you track your estimated time and your actual time it is astonishing how consistent an individual and a team’s velocity is. If you underestimate by 30%, like if you estimate 30% and we need to triple it and add a bit, it will always be like that. You can take a single sprint of velocity and run a whole project off it. I’ve very rarely had to adjust that velocity very much as a correcting factor. We’re optimists, we underestimate, but I think developers can learn to correct for that by collecting data and using that to inform themselves.

Being a Role Model

Derrick:
You advocate having a role model and being a role model. Why and what practical tips can you give on how to become one?

Lorna:
I’m not sure you can ever really become a role model on purpose. That’s just one of those things that happens. To have a role model means to think consciously about what you do and how you interact in an outgoing way with the rest of the community. I’ve been a blogger for years and it’s always been really important to me to share that. Now of course I’m a writer and I write books but it started with a blog of things that I didn’t want to have to Google again.

Being that person and kind of sharing things and encouraging other people to share their own experiences, I think, is part of being a role model. It’s part of thinking about what the community needs, what other people around you would benefit from. How the things you already have and know can be given in a valuable way.

I’m also kind of an active mentor with the PHP mentoring scheme. I find those kinds of programs, or just very informal programs, where you know a group of people who will probably give you some pointers, has been invaluable to me as I climbed the ladder. I think sometimes people forget that at every point in your career someone is behind you on the journey. Even when you’ve only taken two steps, someone has only taken one. We forget to look out for other people when we feel that there’s still a big journey in front of us. It’s really important to remember the whole picture.

Derrick:
Software development is constantly changing with new libraries, languages, other technologies appearing all the time. How can you stop yourself from becoming overwhelmed?

Lorna:
That’s a really difficult one because it can seem like there’s new stuff every week. Either you’re frustrated because you can’t find the time to try them all or you can end up feeling afraid of being left behind. Ask yourself how you got to where you are today. You didn’t do it in one go. Rome wasn’t built in a day and neither were we as developers.

It’s important to be out there, to be aware of what’s happening, to have read the introductory paragraph for all of these various buzzwords. That means that when the opportunity comes up to use them or to apply those tools you’ll have some idea of what the right setting is. Personally I learned most of my skills on open-source projects. I’m always looking for a project which is using the tools that I want to be using in the next job.

That’s mostly how I’ve got to where I am, by making sure that I am playing with technology and being involved with things. Then I already have a grasp of those tools and those techniques so I can very quickly set them up in my commercial projects. That’s really been a valuable approach. Not really on purpose but it’s worked out really well for me through my career.

Confessional Debugging

Derrick:
In the book you confess to talking to your collection of tech-related soft toys as part of ‘confessional debugging’. What is this and how does it help?

Lorna:
Some people call it ‘rubberduck debugging’. It’s that thing where you go to your colleague and you say, “Listen, I’m trying to do this thing and it’s just not working. I installed this and I ran the database patch. Oh, I didn’t update the template. I’ve got it. Okay.” The other person hasn’t said anything yet. It’s that. I’ve been a remote worker for years and years and years. To reach across that divide to explain a problem, it’s much more complicated than just asking the person next to you to come spot the mistake or the missing bracket on your screen. The barrier to doing that is much higher and so I do the confessional thing with whatever inanimate object is around. I have quite a collection of PHP elephants.

Derrick:
The book started out as a talk that covered 27 ways to become a better developer. Are there any that developers disagree or struggle with?

Lorna:
I think the speaking manager one can be quite difficult. Definitely for a long time I just thought people should listen to me because I knew everything. Now I’m a little bit older I realize the importance of echoing those words back and sort of reflecting people’s vocabulary.

The first time that I gave this talk I talked about healthy living. It’s very easy for us to just… programmers are such an intellectual bunch. We live in our heads and we live always online. We can end up keeping terrible hours, eating rubbish because we don’t want to be away from our code and all these new shiny things. I always recommend that people look after their sleep patterns because it’s so fundamental to your mental health. Without your brain being healthy you’re not going to write very good code at all.

The very first time I went on stage and said, “You must practice great sleep hygiene. You should turn off all your devices one hour before bed.” Someone in the audience actually howled. I think that is something that we all struggle with and it’s advice that I sometimes struggle to take myself but it’s, maybe, the most important.

Rome wasn’t built in a day and neither were we as developers

Reading Widely

Derrick:
You recommend developers keep reading. What are some resources you can recommend to those interested in becoming a better developer?

Lorna:
This isn’t just about reading technical books. I do think we should be reading tech stuff. Whatever technology field you work in, find the best of the planet syndicators in your tech area. Definitely make a habit of reading those. In PHP we have the PHPdeveloper.org site, which covers the best of PHP stuff from the whole internet every day, which is brilliant. Also more general sites like DZone cover a really wide range of technologies. Reading their top 10 articles might expose you to something you’re not working with but which might still be interesting.

I also think it’s important for us to read other stuff. Just like learning new languages, I think it’s important for us to read, actually fiction as well. In this very stressful, fast-paced world, it’s very easy to not read anything longer than a tweet or a Hacker News comment. That’s where most of us live. Actually, longer articles, books, it’s all about critical thinking and carrying on exposing yourself to new ideas outside of what can be quite a small and homogeneous world that we live in. Not necessarily geographically, we all interact with people from all over the world, but we can live in a pretty small society. That’s another reason I think it’s really important to just be out there and to keep on reading and being part of a wider world.

Derrick:
Lorna, thank you so much for joining us today.

Lorna:
It was my pleasure. Thanks for having me.

by Gareth Wilson at June 24, 2015 09:57 AM

June 23, 2015

Giles Bowkett

Let The Other 95% Of Reality In

Here's a dramatic reading of a Paul Graham blog post.



Thanks for watching! I hope you enjoyed it.

If you're interested in a more serious analysis, here's a gigantic, detailed breakdown.
American technology companies want the government to make immigration easier because they say they can't find enough programmers in the US. Anti-immigration people say that instead of letting foreigners take these jobs, we should train more Americans to be programmers. Who's right?
First of all, this is a false dichotomy. I don't think I've ever heard "anti-immigration people" say anything about training more Americans to be programmers. The only times I've ever heard "anti-immigration people" express any opinions in American politics, those opinions have consistently been racist opinions about Latinos in general and Mexicans in particular.

But Mr. Graham opened up his post with a cliffhanger. "Who's right?" he asked.
The technology companies are right.
I bet you didn't see that one coming.
What the anti-immigration people don't understand is that there is a huge variation in ability between competent programmers and exceptional ones...
Mr. Graham never bothers to identify "the anti-immigration people," and I'm not totally convinced that they exist at all. I mean I know anti-immigration people exist in general, but I think the "anti-immigration people" Paul Graham wants to "debate" here are fictional. Likewise, I could be willing to assume that people who spend most of their time making racist remarks about Latinos might also be unaware of the varying levels of programming talent. But it's not necessarily true, and I've never really seen anything which proves it to be the case. I've even seen counter-examples.

If we're dealing in unsubstantiated arguments, I would feel more comfortable with an argument like "the set of people who make racist remarks about Latinos is unrelated to the set of people who have opinions about the distribution of programming talent." Although I cannot prove it, I have more faith in it. It also doesn't require you to assume that all these "anti-immigration people" don't know what the word "exceptional" means.

But let's keep following Mr. Graham into the hole he's digging for himself:
...and while you can train people to be competent, you can't train them to be exceptional.
This is simply false. There's a book which explains how to train people to be exceptional. It was written after the author visited specific, unusual schools all over the world, each of which reliably churns out exceptional students, including a tiny Russian tennis school which has produced more top-20 women players than the entire United States, and an American music school which covers a year's worth of music training in seven weeks. (Alumni include Yo-Yo Ma and Itzhak Perlman.)

Continuing:
Exceptional programmers have an aptitude for and interest in programming that is not merely the product of training.
Again, Mr. Graham seems to think the "anti-immigration people" have never heard the word "exceptional" before. This is only just barely better than quoting from the dictionary.

Then we make a pretty wild jump.
The US has less than 5% of the world's population. Which means if the qualities that make someone a great programmer are evenly distributed, 95% of great programmers are born outside the US.
That would be the most gigantic "if" that anybody ever built an essay on, if Mr. Graham were being real with us when he refers to his blog posts as essays, but he's not. They're blog posts. Even if you wanted to humor Mr. Graham's pretensions, this "essay" would be a polemic at best, since it fails his own basic rule that "a real essay doesn't take a position and then defend it."

Nonetheless, this "if" is still a pretty huge "if" to build a blog post on, when your blog is as widely-read as Mr. Graham's.


Does Paul Graham even know who this is?

Mr. Graham doesn't give a moment's consideration to this "if." He just graduates it to the status of fact without ever doing anything to justify that leap. So let's dive in for a second. Are the qualities which make someone a great programmer evenly distributed, throughout the entire world?

Some of these qualities probably are evenly distributed throughout the entire world:
  • Intelligence
  • Curiousity
  • A good memory
  • Eagerness to build, analyze, and experiment
While some other relevant qualities probably are not evenly distributed throughout the entire world:
  • Basic familiarity with machines which use electricity
  • The ability to read and write
  • The ability to read and write English
  • The ability to read and write specific machine-oriented dialects of English
  • A general understanding of Boolean logic
  • A precise understanding of the Unix family of operating systems
  • A lifetime of owning expensive machines, and feeling free to break them in order to satisfy some casual curiousity
Remember, the world is actually a very big place, and it's full of people who don't give a fuck about the Internet. There are still many places in Europe where you can hardly even book a hotel online. To be fair, Vietnamese programmer education sounds absolutely fantastic. And programming languages are not entirely a subset of English. But I think it's safe to say that Mr. Graham's 95% number is flat-out ridiculous, and not worth taking seriously for even a moment.


Access to electricity is not evenly distributed, but maybe a truly great programmer will still find a way.

Mr. Graham didn't bother with this question, however. Instead, he said:
The anti-immigration people have to invent some explanation to account for all the effort technology companies have expended trying to make immigration easier. So they claim it's because they want to drive down salaries.
But this "explanation" did not actually have to be "invented," because it's already a proven fact. Google, Apple, and dozens of other tech companies have been caught illegally colluding to drive salaries down.


The illegal wage-fixing scandal Mr. Graham somehow doesn't seem to know about is absurdly well-documented.

If you don't bother to find things out before blogging about them, then you might think that this illegal conspiracy had nothing to do with salaries and was only about being afraid of Steve Jobs.

You would be wrong.


Google's CEO chastizes Google recruiters for driving up salaries.

Mr. Graham apparently somehow missed this incredibly well-documented scandal that everybody was talking about. So, unperturbed by facts, our misguided hero rabbits on:
But if you talk to startups, you find practically every one over a certain size has gone through legal contortions to get programmers into the US, where they then paid them the same as they'd have paid an American.
I'm sure this is true of startups, but it's false of Silicon Valley in general. And, while Mr. Graham's saying that if you want to understand immigration, you should talk to startups, I believe that if you want to understand immigration, you should talk to immigrants.

I worked with a guy one time who worked harder than me, for longer hours, while making less money, because he knew that if our employer got pissed off, they could put him on a plane back to his war-torn home country. He didn't want to go back and get killed. He wanted to get his family into the United States along with him.

I have absolute sympathy for this guy. First, he was a great guy. Plenty of people could have been mad or resentful in a situation like that. His approach to life was to help as many people as he possibly could. He was able to help me, so I was grateful to him, and he had this awesome attitude, so I admired him. Plus he was funny.

My own parents came to the US from another country, and although it was not a war-torn country, I'm a first-generation American, so even in a festival of straw man arguments like Mr. Graham's blog post, you'd have a hard time lumping me in with the "anti-immigration people." I'm very glad that my friend got to come to this country, and I feel like, for him, accepting a slightly lower wage than I got at the same company was not such a bad deal in context — even though he worked much harder than I did, and was much more important to the success of my team, and I feel kinda guilty about that.

However, Mr. Graham's argument, that great programmers get paid the same at startups whether they're American or not, is completely irrelevant in the case of my friend, a very good programmer who was underpaid at a company which was only just barely too large and established to qualify as a startup.

Most imported programmers in Silicon Valley look more like my friend than the startup programmers Mr. Graham is talking about. And even then, the overwhelming majority of immigrant programmers are worse at programming than either my friend or Mr. Graham's examples.

I've certainly encountered exceptionally talented programmers from other countries, but they're rare for the same reason exceptionally talented programmers from America are rare: exceptional talent is rare, by definition. The silliest thing about Mr. Graham's argument is he wants national policy to be optimized for exceptional cases.

It's odd that I have to say this about a venture capitalist, but Mr. Graham should stop asking for government handouts. He's already rich, and it's not the government's job to make it easy to beat the averages.

Back on the subject of startup founders paying top dollar for foreign programmers, Mr. Graham continues:
Why would they go to extra trouble to get programmers for the same price? The only explanation is that they're telling the truth: there are just not enough great programmers to go around.
That is not the only explanation at all. Here's a simpler explanation: they fucked up. Have you ever met a startup founder? Quite a few of them are complete fucking morons. Even some of the successful ones seem batshit insane.

Plenty of startup founders are quite smart, of course. And I'm not saying that bringing in a great programmer from another country can't be a good idea. But Mr. Graham suffers really badly throughout his blog post from a total blindness to the many, many facts and events which undermine his argument, and to say "the only explanation" in that context just begs for a reality check.

People who run startups make mistakes all the time. They're people.

One way startup founders fuck up: failing to recruit the best programmers they can, irrespective of where they're located. Maybe there are not enough great programmers who are willing to live in San Francisco to go around. But startups which hire remote have a much larger talent pool to draw from. If you adopt a modern working style, you might have less hoops to jump through.

One remote worker had this to say on the topic:
I just finished a remote job search. I'm in Los Angeles, and most of the companies I talked to were in SF. I had previously worked remotely for a company in New York (Etsy), and I was honestly really surprised how hostile SF companies were to the idea.

I have been on both sides of remote work, so I totally get that it's not a slam dunk. It works a lot better for companies that have a strong culture established in a home base, and it works a lot better for experienced folks than green college hires. I have shut down the interview process myself when I felt like working remotely wouldn't work out at particular companies.

Even given all of that, I was pretty amazed how quickly some of the conversations got shut down. No remotes, we don't care who you are or what your experience is. I didn't talk to any companies outside of SF that were that quick to say no.

FWIW I landed at [the YC company] Stripe, which in fairness is probably one of the companies pg had in mind when writing his original article.
As a former San Francisco resident, I honestly think this error is inevitable in San Francisco. One of the few ideas which is utterly unacceptable in any discussion among people in the Bay Area – who are normally very open-minded people – is the idea that the Bay might not be the only place in the universe worth living in.


Mind. Blown.

I liked San Francisco, but it's not the only thing out there. London's better for music. Portland's better for open source. Los Angeles is better for street food, attractive single inhabitants, espresso, weather, parking signs, and in some cases even public transportation. (Bay Area public transportation is better if you want to go a long way, but Los Angeles completely wins at simple, local use.) As for New York, don't even get me started.

Plus, as beautiful as San Francisco is, it's packed with people like this:


Imagine you've already got a hangover and you have to deal with some asshole using an iPad app to control his girlfriend's mind.

Back to Mr. Graham:
I asked the CEO of a startup with about 70 programmers how many more he'd hire if he could get all the great programmers he wanted. He said "We'd hire 30 tomorrow morning." And this is one of the hot startups that always win recruiting battles. It's the same all over Silicon Valley. Startups are that constrained for talent.
But not so constrained for talent that they're willing to explore remote work.

Matt Mullenweg pointed out how absurd this was, and I myself took Mr. Graham to task for this on Twitter:



He responded that remote work is only good for building certain types of companies, but I can't find the remark. I think he deleted it, but it's also possible that Twitter search failed me. I won't get into it, beyond saying that I highly doubt anybody's done any actual research which could grant any credibility to that 20th-century attitude at all.

Mr. Graham continues:
It would be great if more Americans were trained as programmers, but no amount of training can flip a ratio as overwhelming as 95 to 5. Especially since programmers are being trained in other countries too. Barring some cataclysm, it will always be true that most great programmers are born outside the US. It will always be true that most people who are great at anything are born outside the US.
Again, this 95% number is ridiculous, and Mr. Graham is starting to get carried away with this whole "born outside the US" thing. He hasn't even substantiated the claim that most great programmers are born outside the US today, and obviously most people who are great at American football are born inside the US. But rather than slow down, Mr. Graham gets stupid nutty:
Exceptional performance implies immigration. A country with only a few percent of the world's population will be exceptional in some field only if there are a lot of immigrants working in it.
Brazil's population is smaller than that of the United States. The Brazillian national football (soccer) team is the most successful in the world, and has been so for more than fifty years. There are not a lot of immigrants working in the Brazillian national football team.

Given enough time, I'm sure I could find about 50 more counter-examples, at least. The Swiss watch-making industry is probably made up mostly of Swiss nationals. Enzo Ferrari and Ferruccio Lamborghini were both native Italians. Immigration probably does not explain the French advantage in manufacturing cheese, or the Japanese superiority at making anime, or the exceptional quality of British bondage gear. Thailand completely dominates the field of elephant feces tourism, and the source of their advantage is probably not imported talent.

The coup de grace comes next. Mr. Graham, not content with his extra large bullshit enchilada, demands a colossal side order of what the fuck are you even talking about:
But this whole discussion has taken something for granted: that if we let more great programmers into the US, they'll want to come. That's true now, and we don't realize how lucky we are that it is. If we want to keep this option open, the best way to do it is to take advantage of it: the more of the world's great programmers are here, the more the rest will want to come here.

And if we don't, the US could be seriously fucked. I realize that's strong language, but the people dithering about this don't seem to realize the power of the forces at work here. Technology gives the best programmers huge leverage. The world market in programmers seems to be becoming dramatically more liquid. And since good people like good colleagues, that means the best programmers could collect in just a few hubs. Maybe mostly in one hub.

What if most of the great programmers collected in one hub, and it wasn't here? That scenario may seem unlikely now, but it won't be if things change as much in the next 50 years as they did in the last 50.

We have the potential to ensure that the US remains a technology superpower just by letting in a few thousand great programmers a year. What a colossal mistake it would be to let that opportunity slip. It could easily be the defining mistake this generation of American politicians later become famous for. And unlike other potential mistakes on that scale, it costs nothing to fix.

So please, get on with it.
As far as I can tell, his argument is that we have to take action immediately, because conditions could change over the next 50 years. And it would cost politicians nothing to abandon anti-immigration policies, somehow. And nobody will remember Ferguson, or the wars in the Middle East, or the bank bailouts, or Edward Snowden, or climate change, but we'll curse the name of every senator who ever voted against H1 visas.

And somehow, we can find "a few thousand great programmers every year." No, we can't. Mr. Graham flatters himself when he refers to his blog posts as essays, but back in the day, he actually did write essays. One of his best essays argued that identifying great programmers is incredibly difficult, even for other programmers.
It's hard to tell great hackers when you meet them... You also can't tell from their resumes... the only way to judge a hacker is to work with him [or her] on something...

Hackers themselves can't tell how good they are...

If there is a Michael Jordan of hacking, nobody knows, including him [or her].
So we need to import a few thousand exceptional programmers, even though we have no way to identify them in the first place. And language barriers will not make identifying them any harder. And somehow we're going to do this on a yearly basis.

Meanwhile, in reality, Mr. Graham's worst fear came true a long time ago. Most of the best programmers have already collected in one hub, and it's not here, or there, or anywhere. It's called GitHub. It was built as a distributed company around a distributed version control system, and — because Conway's Law works in both directions — it is training every programmer in the world to do distributed work.

Silicon Valley was once the center of the universe for programmers. In a sense, it mostly still is, kinda. But the real center of our universe is no longer a physical location. The real center of our universe is a virtual location which is training us all, every single day, to work remote.

And even GitHub is only barely central. There's Bitbucket and GitLab, and any communication through GitHub is typically supplemented with additional communication through IRC, email, videoconferencing, Slack, Twitter, SMS, and more. The best-case scenario for face-to-face communication in 2015 is that it's how you augment your other channels.

Do we seriously need to explain to a guy with three Ivy League degrees that a decentralized networking technology will have a decentralizing effect on every industry that uses it? Can't we just send him to the Wikipedia page for economics or something?

Some of Mr. Graham's other writing is much better than the nonsense I've dug into here. You can also create a great Paul Graham essay if you take one of his classics, The Python Paradox, load it up in Vim, and run a quick s/Python/remote/g. But if you ever took his arguments on immigration seriously, even for a fraction of a second, then you owe it to yourself to do the following simple exercise.

Make a list of all the programmers who fit these criteria:
  • They created a technology which completely redefined its category.
  • You can't find them living in the Bay Area.
  • You can find them working on GitHub.
Your list will be big, and it will include Linus Torvalds (who lives in Portland), John Carmack (a small town in Texas), David Heinemeier-Hansson (Chicago and/or Barcelona), John Resig, Jeremy Ashkenas, Rich Hickey (all in New York), and many, many others.

Or, for a more amusing list, count the number of YC companies which hire remote, despite Mr. Graham telling me on Twitter that hiring remote isn't appropriate for the type of work YC companies do. I know of at least seven such companies, and I haven't even tried putting it in a search engine.

The alleged Bay Area "talent drought" is only half real. Programming skill is certainly both valuable and rare (although well-managed tech companies are probably rarer, and that might not be a coincidence). But the other half is self-inflicted, because an industry organized around innovation and disruption is clinging to a bafflingly archaic work culture. VCs and founders are shooting themselves in the foot, while the execs at established companies form illegal conspiracies to keep programmer salaries low.

("Low" is a relative term, of course, but housing costs are relative too.)


No thanks.

Let The Other 95% Of Great Programmers In is the worst thing Mr. Graham has ever put on paulgraham.com. That's why I portrayed him as intoxicated in the dramatic reading. I couldn't think of any other way to reconcile his obvious intelligence with the fact that he wrote that thing.

(Likewise, I used the uniform of a Silicon Valley middle manager as my costume because I don't think Mr. Graham's given one iota of thought to what these words might mean coming from Silicon Valley in general. It's entirely possible he constructed his wretched pile of illogic with some honest mistake at its foundation. But if that "essay" made any real progress in national politics, it would be promoted for incredibly dishonest purposes, by incredibly dishonest people.)

In conclusion:


Dat Footnote Tho


Mr. Graham's post contains a few footnotes. I'm not going to bother with them, except to point out that one footnote includes the hilarious phrase "it should be easy to write legislation." And to quote this bit:
it is dishonest of the anti-immigration people to claim that companies like Google and Facebook are driven by [a desire to drive down salaries]
He says this despite the fact that Google was sued for illegally agreeing not to hire people away from numerous specific companies — which suppressed salaries — in a well-documented case which Google has not contested. The judge rejected Google's $324.5M settlement offer because it was too low.

Again, quoting Eric Schmidt, Google's CEO at the time:
Google is the talk of the valley because we are driving up salaries across the board... We need to get this fixed.
If your CEO tells you that driving salaries up is a problem, what direction might you imagine he prefers?

Mr. Graham's argument equates Google with startups, but calling Google a startup today is like calling Microsoft a startup in 1998. It verges on delusion and it leads to completely ridiculous claims. Graham says "the anti-immigration people" are being "dishonest." But I'm a first-generation American. My parents are immigrants. And I'm pointing out something Google actually DID.

If your argument implies that it is dishonest for people to remind you of facts, your argument is probably flawed.



Speaking as a first-generation American, I'm not against immigration. I'm against indentured servitude. I'm against corporations using fraud and collusion to evade both labor laws and the real market price of programming ability. And I think most American programmers are uncomfortable with H1 visas for the same reasons.

By the way: at the company I work for, Panda Strike, we've hired programmers from France, Argentina, Germany, and India. Some of them live in the US, some of them live in their home countries, some of them have wandered through Australia and Thailand while working for us.

We're certainly aware that programming talent comes from all over the world. And I'm not saying American immigration law is perfect. There are foreign-born programmers we would hire in a heartbeat if their visas didn't make them captives of their current employers.

But we use modern technology and modern development practices, and we recommend you do the same. One easy way to start: let the other 95% of American programmers in. If you're building a company, and you want access to the best possible talent pool, you need to know how to manage remote developers. If you want to learn about that, check out our blog.

My opinions are my own, of course. That was just a shout-out.

Also, a quick note: there are some uncredited photographs in the video. Lost track of the links when I was making it. If they belong to you, sincere apologies, and feel free to email me: gilesb@gmail.com.

by Giles Bowkett (noreply@blogger.com) at June 23, 2015 09:58 PM

Dave Winer

For comatose Knicks fans everywhere

When you wake from a multi-year coma and your first question is Are the Knicks the NBA champions? I have created a wonderful and easy to use site that will give you the answer in an instant!

http://aretheknickschampions.com/

It probably won't require updating for years, if ever.

It was inspired by Scott Knaster's fan site for the Warriors.

It was also the content of my 100,000th tweet.

June 23, 2015 12:43 PM

Fog Creek

Switching from For Your Server to FogBugz Ocelot Meant No More Maintaining for Ilium Software

Michigan-based Ilium Software have been designing and creating information management tools for mobile devices since 1997. They’re a long-time Fog Creek Software customer, having been using FogBugz since version 3, and Kiln since it was first released. We spoke to Ken Morse, Managing Partner at Ilium Software, about their experience of switching from For Your Server to On Demand and FogBugz Ocelot.

VisaDebit-PC-iOS

Using for Your Server

“We’ve been using FogBugz as a helpdesk as well, but started out just tracking bugs and enhancements and we used a separate system just for customer-facing stuff, but it was a pain”. With FogBugz, it has been “really handy to have project cases and customer issues all in one place.”

However, whilst “overall, we were pretty happy with our experience of the self-hosted version. In the back of mind, I kept thinking ‘why are we maintaining this thing, it’s just crazy’… if something happens, that’s the big thing, it’s us that has to sort it out”. Not only that, but Ken says “maybe your server is paid for, but at some point it’s going to need an upgrade. A hard disk goes bad, there’s time there, downtime, there’s a lot of cost to doing it yourself”. So they looked around for alternatives, “but our experience with Fog Creek over the years was so positive… it made the decision [to move to FogBugz Ocelot] pretty easy”.

Moving to FogBugz Ocelot

So they made the switch from for Your Server to FogBugz Ocelot. “When we decided to make the move, we got a knowledge base, checklists, things to walk-through, it was very helpful. It went smoothly”. And it “got us out of the business of having to maintain FogBugz, which is not part of our core business. I have not been sorry for a second… it just performs great.” “We had FogBugz on some pretty decent hardware so it ran great for our little company, but we even gained a little bit performance-wise moving to On Demand”. It’s also “made access smoother for everyone… sometimes we have contractors come in, and we had to add them to the Firewall and the VPN. On Demand makes that so much simpler.”

“Soup to nuts, it’s a great product, it’s extremely easy to use… I’m really, really happy with it”. “If you have questions or need help, between the knowledge base and contacting Fog Creek, I just feel like you’re fully covered.”

by Gareth Wilson at June 23, 2015 10:37 AM

June 22, 2015

Dave Winer

The confederate flag is a hate crime

I spent a some time in northeast Florida a few years back. Every so often a bit of the rural culture would show up there, though mostly it is an expensive coastal enclave, separate from the rural South in central Florida and south Georgia. The confederate flags didn't bother me much, I was told they were about heritage, and who cares if people in the South want to remember the Civil War as a rebellion, not a war to keep slaves.

I didn't wonder what it would be like to be black and see this symbol of their enslavement in everyday life, until I saw a man with a swastika tattoo in a convenience store in Palatka, an inland town. His van also had swastikas, confederate flags, slogans about white power. Then I understood how disturbing it must be to be black and to live among people who advocated your extermination so openly. The swastika conveys all that, for my people.

Disturbing, until last week when nine black people were killed in a church in Charleston, by someone with the same political values as the man in the Palatka parking lot. Now they're killing more than a random man, they're killing women too, in a church. Good people, really the best of America. Dead. In the cause of hate.

As long as the confederate flag is a symbol of government in the South, flown over one state capital, in the flag of another, on state-issued license plates, the message is clear to white supremacists. We are with you. And that's why, as long as the confederate flag is a symbol of government in the South, the South itself is a hate crime.

I know there are good people in the South, thoughtful people, who care about others. Think about it this way. As long as the rest of America tolerates this hate, we're standing with you, in inaction.

June 22, 2015 12:45 PM

Tim Ferriss

TF-StitcherButton

Adam Gazzely on the Tim Ferriss Show

“My lab is interested in pursuing how we can enhance cognition to improve quality of life.”
– Adam Gazzaley

Dr. Adam Gazzaley (@adamgazz) obtained an M.D. and a Ph.D. in Neuroscience at the Mount Sinai School of Medicine in New York, then postdoctoral training in cognitive neuroscience at UC Berkeley. He is now the director of the Gazzaley Lab at UC San Francisco, a cognitive neuroscience laboratory.

His recent studies go far beyond mere description — he and his lab are exploring neuroplasticity and how we can optimize cognitive abilities, even in healthy adults. So, what happens when you combine cognitive-focused video games with neurofeedback, magnetic and electrical stimulation, and even performance-enhancing drugs? Well, that’s just one of many things we cover in this conversation.

As someone with Alzheimer’s disease and Parkinson’s disease on both sides of my family, I find Adam’s work to be of incredible importance and promise.  I hope this discussion blows your mind, in the best way possible.

Enjoy!

TF-ItunesButtonTF-StitcherButton

Want to hear more from world-class scientists?
Check out my conversations with Dr. Peter Attia. In the below episode, we discuss life-extension, drinking jet fuel, ultra-endurance, human foie gras, and more (stream below or right-click here to download):

Want even more from unorthodox scientists?
Listen to my conversation with Dr. Rhonda Patrick. In this episode, we discuss life extension, optimal performance, and much more (stream below or right-click here to download):


This podcast is brought to you by a new sponsor, LegalZoom. Matt Mullenweg (CEO of Automattic – now worth more than a billion dollars) first incorporated his company on LegalZoom.  LegalZoom, which I’ve used myself, can help you with almost anything legal, including setting up a will, doing a proper trademark search, forming an LLC, setting up a non-profit, or finding simple cease-and-desist letter templates. LegalZoom is not a law firm, but they do have a network of independent attorneys available in most states. They can give you advice on the best way to get started, provide contract review, and otherwise help you run your business. Use the code “Tim” at checkout to get $10 off your next order. Take a gander at everything you can get for a fraction of what you’d expect — LegalZoom.com

This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Give it a test run..

QUESTION(S) OF THE DAY: Are you afraid of losing cognitive function with age? If so, WHAT are you doing to prevent it? If nothing, why? Please share in the comments.

Scroll below for links and show notes…

Selected Links from the Episode

The Lab: Gazzlab.com | Photography: ComeWander.com

Show Notes

  • Why Neuroracer was considered a ‘game changer’ [7:40]
  • Theories of cognition [13:50]
  • On making the cover of Nature magazine [17:35]
  • The self-talk behind Adam’s crazy idea to build a video game to rewire the brain [19:20]
  • What inspired Adam to become a scientist [21:40]
  • Why Gazzaley Lab is unique/unusual and concepts that have jumped into the private sector [25:35]
  • Why Gazzaley decided to focus on improving cognition [34:40]
  • How Adam Gazzaley thinks about “success” [39:40]
  • Vetting people who want to be a part of Gazzaley Lab [34:05]
  • Common misconceptions about the brain and cognitive function [36:15]
  • On the likelihood that pre-existing video games have similar cognitive effects to cognition as as described in Gazzaley Lab’s video game research [43:20]
  • Most gifted books [47:10]
  • About the ‘Neuroman’ project [50:50]
  • Learn more about the games Gazzaley Labs has created to improve cognition: MetaTrain, Body Brain Trainer (BBT) and Rhythmicity [56:50]
  • How inspiration for Rhythmicity came from New Orleans, The Grateful Dead, and the AARP [1:05:30]
  • The origin of Adam Gazzaley’s interest in photography [1:10:20]
  • Morning rituals for Adam Gazzaley [1:16:20]
  • Rapid Fire Questions: Inspiration for downtimes, most listened to music, favorite cocktails, losing an eye, and plans for virtual reality [1:25:00]
  • Exploring the crossroads of hallucinogens and neuroscience [1:40:50]
  • Shortlisted compounds for pairing pharmaceuticals and video games to improve cognition [1:43:20]
  • On the neurological impacts of modafinil [1:46:05]
  • The most exciting studies related to Transcranial Electrical Stimulation (TDCS) [1:47:20]
  • Advice to Adam Gazzaley’s thirty-year-old self [1:51:20]
  • What Adam Gazzaley would do with an additional 100 million dollars [1:52:50]

People Mentioned

by Ian Robinson at June 22, 2015 07:41 AM

Dave Winer

Fargo blogs and rssCloud

This is a test post to verify that the implementation of rssCloud in Fargo works.

When it works, you will be able to get instant updates to Scripting News, for example, if your RSS reader supports the rssCloud interface.

River4 supports rssCloud, as does WordPress.

Fargo v1.71 is now released.

How to test

  1. Make a change to one of your public outlines.

  2. Look at the RSS feed. View source if the browser is hiding the XML.

  3. There should be a <cloud> element in the feed.

Scripting News

My blog, Scripting News, is published with Fargo.

Here's the feed.

June 22, 2015 01:17 AM

June 21, 2015

Mark Bernstein

In The Woods

A well-paced and intriguing police procedural, winner of an Edgar Award and formally interesting because the narrator is an investigator but not the focus or, really, the protagonist. Rob Ryan of the Dublin Murder Squad investigates the body of a child murdered near his own childhood home; twenty years before when he was 12, Ryan had gone out to play in these very woods with two friends. Only Ryan came home from that adventure, he could not (and still cannot) remember what happened, and the police investigation went nowhere. The new investigation seems likely to follow the old case into the capacious storage racks beneath Dublin Castle.

June 21, 2015 07:56 PM

June 19, 2015

Dave Winer

riverBrowser open source release

Rivers are very important structures in my 2015 world, as it's shaping up.

They appear on the home pages of Scripting News, Podcatch.com. Subsets of rivers are on every page rendered by Liveblog.

Rivers are not only important here, but they also form the central structures of Twitter and Facebook.

Doing a good job of generating and viewing rivers is a pretty big deal. However, until now my work in this area was not organized. This open source release in an attempt to add organization.

GitHub repo

Here's a link to the GitHub repository for riverBrowser.

The readme explains how to call its main routine, httpGetRiver.

Sites that use this toolkit

I've converted most of my river sites to use the new toolkit, including:

  1. Scripting News

  2. Podcatch

  3. TechBlast (a new site for tech news)

  4. Radio's Rivers (my original collection of rivers)

The other side

Rivers are an open format, defined by the spec on riverjs.org.

River4, a Node.js aggregator that's also open source, generates rivers.

Still to-do

The rivers that are integrated in River4 have not yet been updated. I wanted to give the community a chance to review the implementation here, and try it out on their own rivers, before taking a chance on breaking people's installations. So this review is important if you want a relatively breakage-free update.

June 19, 2015 06:25 PM

Fog Creek

How Rogue Amoeba use FogBugz Ocelot for Bug Tracking and Great Customer Support

Rogue Amoeba is a software company based out of Boston, USA. Since 2002 they’ve been making award-winning audio tools for Mac OS X. We spoke to Paul Kafais, Founder and CEO of Rogue Amoeba, about how FogBugz Ocelot has helped them to track bugs and provide great customer support by being able to work on bugs and customer enquiries together, in one place.

Screen Shot 2015-06-19 at 10.18.39

The Problem

When they began they used email for customer support – “everything came into my inbox and I would answer it”, but then they hired support staff and “started with a help desk product”. This helped, but it wasn’t enough – “having support and bug tracking in one place is something we wanted to do”. Not only that, but they were still writing each response from scratch – “sometimes we found that we had to explain how our product works over and over… having to type it out every time” and that meant that “we were writing things to customers and they could come off a bit terse, and we needed something that could fill in the good feeling, the politeness.”

The Solution

So they looked around for alternatives and came across FogBugz. “The big thing for us was the bug tracking feature in addition to the help desk” and “we looked at various features and said ‘oh yea that would be useful'”.

They began using FogBugz, initially “exclusively for customer stuff” like support, but its use grew to cover “issue tracking or bug tracking” for development activity too. For both of these uses, they make extensive use of Milestones. So they order all things by a particular milestone, like cases, features and fixes and this gives them a full view of “what is going to be in release 2″ for example, and this “let us build a little bit of a roadmap”. Or “if we decide we’re not going to work on something we’ll put it in the ‘Archived’ milestone. And maybe later we’ll see that we’ve got a dozen or so more requests for it, so we’ll reactivate it.”

The Results

Since making the switch to FogBugz they have found that “having the customer communication together with feature requests and bugs, was really useful so we could communicate with a customer and say ‘oh yea that’s fixed in so and so version'”. It also meant that staff could seamlessly transition between roles, for example, “one of our support techs transitioned to development, so he’s seen both sides of it.” They could also put an end to the duplication of responses, as they “found that snippets were really useful to have, instead of having to type that over and over again.”

Overall, Paul says “it’s reliable, well-tested, well-used” and now they’re on FogBugz Ocelot they’ve enjoyed the performance upgrade too – “the search works well” and “the pages load quickly”. “It’s a solution that has worked for us.”

by Gareth Wilson at June 19, 2015 11:02 AM

June 18, 2015

Dave Winer

Give up the Confederate flag

Imagine if Germany flew the swastika over its main government building.

That's pretty much analogous to South Carolina flying the Confederate flag over their state capitol building.

Also, the official state flag of Mississippi contains the confederate flag within it. Alabama and Florida have the bars.

June 18, 2015 09:35 PM

Tim Ferriss

TF-StitcherButton

Sam Kass, right, holding court. (Photo: Bob Nichols, USDA)

Sam Kass, right, in official White House gear. (Photo: Bob Nichols, USDA)

“Yankees, we’ve won!”
– Austrian sous-chef to unprepared Americans hustling at a Michelin 3-star restaurant

“75% of success is staying calm. The rest you figure out.”
– Sam Kass

Sam Kass almost became a pro baseball player.  Instead, he pivoted a history major from U. Chicago into becoming the private chef for the Obamas in the White House.

He then broke into national nutrition policy and was named #11 on Fast Company magazine’s 2011 list of “100 Most Creative People” for his work, which focused on establishing private-sector partnerships to reduce childhood obesity to just 5% by 2030.

His story is amazing, his career turns unexpected, and his trials by fire hilarious.  

In this conversation, we talk about:

– Baseball and the art of fielding, plus how he set records at U. Chicago
– His odd leap to the culinary world and escapades one of the best Austria kitchens
– His favorite books, routines, and breakfast eggs
– Simple cooking tricks and common mistakes
– A go-to meal for impressing any date
– Nutrition, top-soil depletion, and organic food
– Why he doesn’t like black pepper
– And much, much more…

We delve into his incredible batting average (literal and metaphorical), his trials by fire, what it’s like to cook for the First Family, and well beyond.  Enjoy!

TF-ItunesButtonTF-StitcherButton

Want to hear another podcast from a world class chef? Listen to my conversation with Andrew Zimmern. In that episode, we discuss simple cooking tricks, developing TV, his success secrets, and beating addiction (stream below or right-click here to download):


This podcast is brought to you by Mizzen + Main. Mizzen + Main makes the only “dress” shirts I now travel with — fancy enough for important dinners but made from athletic, sweat-wicking material. No more ironing, no more steaming, no more hassle. Click here to see the exact shirts I wear most often.

This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Give it a test run…

QUESTION(S) OF THE DAY: If you had to pack the essence of life into a burrito, what would that burrito look like? OR What simple meal have you used to impress dates? Please let me know in the comments.

Scroll below for links, resources, and show notes…

Selected Links from the Episode

avec | Alinea | Frankies 457

Twitter | Instagram

Show Notes

  • Eggs, coffee, and morning routines [5:50]
  • Why Sam Kass loves baseball [9:25]
  • Fulfilling University of Chicago academic requirements while setting records as a baseball player [11:55]
  • The story behind how he was baptized by fire in kitchens [17:05]
  • Mental preparation for high-stress situations [22:35]
  • Unusual restaurants that put out great food [25:35]
  • If you had to limit your herbs or spices to 3 choices for the rest of your life, what would they be? [27:55]
  • How Sam Kass was introduced to the Obama family, and what it’s like cooking for the POTUS [33:15]
  • Food pet peeves [39:00]
  • On ecosystem challenges, including soil degradation and the declining bee population [43:05]
  • Rapid-fire questions: Who is successful, most gifted book, favorite documentary and a purchase $100 or less that has had the most value? [57:40]
  • More morning routines [1:03:05]
  • “What is the best use of wine that’s too old to drink?”
  • “What should home chefs stop doing?”
  • When to know your pan is hot enough to sear a fish and what oil to use [1:13:35]
  • “When you fall into a rut in the kitchen, what resource do you turn to for inspiration?”
  • Simple starting points for incorporating more healthy food [1:16:50]
  • “What’s the best meal to impress a girl but is easy to make?”
  • “What dish have you most frequently made for house guests?”
  • Common mistakes made when grilling [1:27:30]
  • “What is the best way to systematically refine and develop your pallet.” [1:28:35]
  • “If you had to pack the essence of life into a burrito, what would that burrito look like?” [1:31:15]
  • Advice to a younger Sam Kass just after graduation from the University of Chicago [1:33:45]
  • Sam Kass’s one “ask” of the audience [1:36:45]
  • Find Sam on the Internet:

Twitter | Instagram

People Mentioned

by Ian Robinson at June 18, 2015 06:29 PM

Dave Winer

Why aren't the BigCo's converging on JavaScript?

Everywhere I look individual programmers are getting on board with JavaScript. It really is something. After a couple of decades of fragmentation in the development world, we now have what I called, in 1995, a consensus platform. Chances are pretty good if you and I are working on server code, we're both working in Node.js. And if you and I are writing code that runs in the browser, the chances are 100 percent that we are both working in JavaScript.

Yet almost all the big companies are trying to create their own languages, presumably with proprietary or patent secret sauces, that are not JavaScript.

If we were healthy as an industry in ways that we are clearly not, we would see this coming-together as an opportunity to become more efficient. We'd be looking for opportunities to factor redundancy from our platforms, for example reducing our reliance on CSS and HTML, and perhaps eliminating the need for server code. These are serious possibilities. There isn't much functionality left that must be on the server. If we concentrated real hard, we could make those go away.

But the BigCo's seem to want the chaos? And as a result they'll need lots more programmers to maintain all the incompatible stacks. I don't think this is driven by business needs, rather it's programmers trying to be sure they continue to have jobs. Re-inventing stuff that already works pretty well. Job security.

Reminds me of all the incompatible BigCo networking products that were swept off the table by the emergence of the web as the consensus platform in the early 90s. JavaScript is that strong a force in 2015.

June 18, 2015 06:26 PM

Fog Creek

FogBugz Ocelot – The Fastest, Most Powerful Way to use FogBugz

“The new hawtness” are the words Rich, our COO, used to describe FogBugz Ocelot. I’ve no idea what that means, but not wanting to seem un-cool I duly nodded knowingly. What I do know is this: FogBugz Ocelot is fast and feature-filled.

agileSmall

What’s in FogBugz Ocelot?

It’s our most powerful version yet. We’ve updated the UI and added bags of new functionality, including things like:

It’s Faster Too

We didn’t just stop at functionality, we improved the speed and responsiveness of FogBugz too. We took the parts of FogBugz that people use 90% of the time, and we re-wrote them, from scratch.

We re-worked the case and list pages so they now load super fast. You can also see more of the information you need, at a glance, with lists of case subscribers and those who are working on a case.

Search is much quicker too, with a new search guide and auto-complete, so that you can find data faster.

And it has been a big hit with our beta testers and early users. Here’s just some of the great feedback we’ve been getting:

  • “I love the faster filter interface!” – Paul, FogBugz user for 1 year
  • “The speed improvements are great” – Christian, FogBugz user for 3 years
  • “Loving the speedy new UI. You all rock” – Geoff, FogBugz user for 1 year

Learn more about the new, fast and feature-filled FogBugz Ocelot and try it for yourself. Here’s further info for:

by Gareth Wilson at June 18, 2015 02:17 PM

June 17, 2015

Dave Winer

Dropbox's new "Requests" feature

This sounds like a really useful feature.

How it works: You set up a request on dropbox.com, and people can send you files via a web form. They show up in a folder in your Dropbox.

For example, here's a request where I ask for a nice picture. I emphasize the word nice. Thank you. Let's see what happens.

I can see this becoming part of a CMS.

Any other ideas??

PS: Paolo Valdemarin uploaded this pic probably from BloggerCon IV, with Marc Canter, Susan Mernit, Richard MacManus, Mike Arrington, Steve Gillmor, Lisa Williams and myself.

June 17, 2015 08:28 PM

Social networking without spoilers

Posted on Facebook yesterday.

What if you could put a dialog-based spoiler alert on a post.

A picture named noSpoiler.png

You wouldn't be able to read the comments until you confirm that you know there are spoilers below, and be given a chance to know what the spoilers relate to.

Or -- even better -- I could say the post is only visible to people who have declared in their prefs that they've already seen the season finale of Game of Thrones season 5.

Think of all the new metadata you'll get.

Of course if HBO NOW had community features, it would be killer there, because they would know that you've already seen the episode, without the user doing anything. Or Amazon or Netflix, for their shows.

June 17, 2015 06:49 PM

Why it's wrong for a white person to self-declare as black

In an op-ed piece in today's NY Times Tamara Winfrey Harris explains: "Racial identity cannot be fluid as long as the definition of whiteness is fixed."

It's rare that a moral argument has such a precise and simple resolution. You can only go one way if it makes sense to go the other.

Kareem Abdul-Jabbar, who is over 7 feet tall, made a similar analogy in a Time essay. You can allow a white person to self-declare as black, if he can self-declare as 5 foot 8 inches tall.

We may want to live in a world where a black person could decide to be treated as if they were white, but we do not live in that world.

In other words, there are some things about us that are immutable.

June 17, 2015 04:30 PM

Fog Creek

All Software Problems are People Problems – Interview with Roy Osherove

.little {font-size: 75%}
All Software Problems are People Problems – Interview with Roy Osherove

Looking for audio only? Listen on

In this interview with Roy Osherove, author of ‘Notes to a Software Team Leader’, we discuss how you grow self-organizing software teams. We cover the importance of developing team members, different phases of leadership, using code reviews for learning, and some common mistakes made by new tech leads. For more about these topics, Roy blogs about team leadership and development practices on his blog.

Content and Timings

  • Introduction (0:00)
  • About Roy (0:23)
  • Why Developers Shouldn’t Fear Leadership Roles (1:33)
  • Growing Team Members (3:38)
  • Phases of Leadership (9:34)
  • Learning through Code Reviews (12:10)
  • Tips for Tech Leads (14:30)
  • Common Mistakes of new Tech Leads (16:54)
  • Recommended Resources (19:06)

Transcript

Introduction

Derrick:
Roy Osherove is head of software infrastructure at Siemens Healthcare based in New York. He’s been an Agile consultant for more than 10 years and is the author of a few books, including ‘The Art of Unit Testing’ and ‘Notes to a Software Team Leader’. Roy, thank you so much for joining us today. Do you have a bit to share about yourself?

About Roy

Roy:
There are three things that I’m passionate about. I’ve been in the software industry for 17, maybe 18 years now. There are three things that I’m really passionate about. One is unit testing and test-driven development. The second one is continuous delivery and deployment and automation, DevOps, basically. The third one is leadership, basically connecting all these dots, because what I find is that even when you know the right things and what to do, actually getting other people to do those things with you is horribly difficult. No one prepares you for that.

I’ve been teaching unit testing for 10 years now. I keep repeating the same answers, and I keep getting the same questions. At some point, you start to realize, “You know what? Maybe something is not effective here.” You start looking outside the boundaries and say, “Okay, what’s missing for unit testing to actually take off, for TDD to actually take off, for continuous delivery?” All those things, I find that leadership is the glue that connects and actually drives us towards where we actually want to go. Of course, we have to know what it is. That’s where the other skills come in.

Why Developers Shouldn’t Fear Leadership Roles

Derrick:
Often developers can be reluctant to put themselves forward for leadership roles, but you
don’t think it’s something anyone should fear. Why is this?

Roy:
Maybe I can rephrase it. I’m not sure that it’s not something you shouldn’t fear. I think fear is actually pretty healthy. I think you should do things that scare you. What I’m saying is that it’s not something that should block you. The fear should not block you from actually doing it. There’s something that I saw a few days ago. Someone wrote, I think, on Twitter or something that really resonated with me. The reason that a lot of managers suck today, or a lot of leaders are not really good at their job today, is because people like you don’t take on those roles. People like you who actually care, who actually wants to see these things through. Then the people who either care less or don’t understand what they’re getting into, they’re more likely to take these roles.

The reason that I think that even if it is scary it shouldn’t block you, oh there are several reasons. One is doing things that are beyond our comfort zone, that we’re afraid of doing or we never thought we’d do, actually grows us and makes us better, and increases our skill and practice, and actually makes us more valuable. Not only is it good for your resume, but it’s also good for you, because you can come back to doing the other work if you want to and then have a different perspective on it. You become better by looking at the same work from multiple points of view.

The second main reason why I think it should not block you is because, remember all those things that you’ve always wanted your manager or leader to do? Now you can actually get to do them, by getting the budget for that build server that everybody’s waiting for, for that software, for getting more memory or laptops for the developers, for getting whatever it is you need to get to make the environment better. If the environment ever stopped you, this is a great chance to change the environment, not just bitch about it, basically.

Leadership is the glue that connects and actually drives us towards where we actually want to go

Growing Team Members

Derrick:
In your book Notes to a Software Team Leader, you say, “A team leader grows the people on their team,” and that this should be the key thing driving your behavior as a lead. Why do you think this is so important?

Roy:
I think that it’s almost required. The reason I think it’s required is because if you don’t do it, you’re basically stopping in the same place and you’re not actually changing anything, except maybe just signing budgets, because, for example, if you know what it is that has to be done, if you want the team to do unit testing or test-driven development, but the team itself thinks it’s not such a great idea, how do you actually get them to do it without growing them in the right direction?

Another thing that happens is that a lot of teams today are actually not in a position where they can actually make good decisions. They’re in positions where you’re actually, as a leader, you are the bottleneck. They come to do with every little decision, with everything. It’s like kids that always come to you, if you have kids, always come to you on every little argument instead of settling it themselves and finding a good solution. What we want is for a team to grow their skills so they can handle the current reality that they’re in.

Most teams are in what I call survival mode. Survival mode is basically that terrible place where you’re just chasing your own tail and you’re just putting out fires, instead of actually planning and doing things you want to do. You keep handling unplanned work, or you’re so far ahead and overcommitted that you don’t have time to do things right and to actually do the right things. To get out of survival mode, you have to make time to learn, and you have to get the team into a learning mode where they can learn new skills so they can avoid the future survival modes.

As they learn, they gain new skills, and those skills will help them figure out what happens when this situation comes in, what happens when another situation comes in. Suddenly, the team can handle more situations in a better way. For example, writing better code so that you don’t go around being scared of refactoring it. That’s a skill, and it takes time to learn. All these things, they come together.

Growing the people on the team there’s one last part. As a team leader, one of the things that was always missing to me is a value system. What’s the point? What’s the point of me as, let’s say, a line manager or a team leader or a Scrum Master, how do I know I’m doing the right job, I’m doing a good job, I’m doing a job well? You can say, “You’re doing the job well if the team’s delivering.” If the team is delivering but you are basically the one who’s pushing for it, is it the team, or is it you? If you’re away for a week, can the team survive without you? Are you the bus factor? In other words, if you get hit by a bus tomorrow, could the team continue functioning without you? If the answer is no, then you didn’t really make a team. What you made is a bunch of people to help you.

If you’re the team, that’s okay, but you’re not a team leader. You’re just basically either an architect or something, and you just have a bunch of Santa’s little helpers. There’s a difference. The difference is that the team is not really capable of doing anything without you, or they’re capable of doing very little things without you. To me, a value system is the ability to, when confronted with difficult questions, such as, “Should I do this? Should I attend this meeting, or should I do something else?” I always have an answer based on the global question is, “What enables a team or what teaches the team to become better?”

Every week, I can ask, “Does the team need me more or less than last week?” If they need me more than last week, then I’m not doing my job. If they need me less, if I make myself less needed, if I remove myself from the equation, not just by disappearing but by enabling the team to do the things that I know how to do, then I’ve basically made them better, and I’ve actually taught them how to do my job, which basically makes me almost unneeded. That feels scary, but really what it makes you is, it makes you a much more scalable leader, because now instead of just leading that team, you become the leader in the group that you can move between teams and make them better. People can drop you into a team, and you make the team better just by being there. That’s actually more valuable than what you did before.

Derrick:
How do you handle people who don’t want to grow?

Roy:
People who don’t want to grow, usually there is always a reason. A person has a reason why they don’t want to maybe learn a new skill and get out of their comfort zone. There is no one way to handle it. Usually it’s a one-on-one, sometimes multiple times, coaching and talking about the fact that, in my team, I ask people, I expect people to continuously learn new skills. That is something that I don’t compromise on. However, that conversation might come only after maybe six months or something, where things are not working out.

Yeah, it’s not always easy, but it’s one of those difficult conversations that I think as a leader you have to learn how to do. It’s not going to be easy. Again, I don’t want it to be easy, because if it’s easy, you’re not learning anything new. It’s supposed to be difficult. Gerry Weinberg has a book called Becoming a Technical Leader. In that book, he says management done right is a very difficult job. A lot of managers like to take the money and not do all the hard parts.

Phases of Leadership

Derrick:
Talking about different phases in a team, teams aren’t in one binary phase. Often they move between them. How can a leader understand what phase a team is in?

Roy:
The three phases are, what I usually look at are survival mode, where you don’t have time to learn, you don’t have time except only to react; learning mode, where you’re supposed to do things and fail and learn and do things slower; and self-organization, where the team can handle their situation without requiring the leader. Usually the questions are simple. You know you’re in survival mode if you don’t have any time to do the things that you would like to do, and you keep reacting instead of planning. Even if you have time to send people to a two-day course, it doesn’t mean that you have time to implement what they learn. If you don’t have time to do slow practice, you’re in survival mode.

It could be that a part of the team is in survival mode and a part of the team is self-organizing. If you have a large enough team, you might start to get cliques where some people are doing okay, some people are definitely buried deep. To me, what I see is that that is a function of knowledge distribution. If there is no cross-training in the team, and you get a bunch of people that have this problem that’s their problem, and a bunch of people have a different problem that’s their problem, but the team is a team, the way I see it is that it always hunkers down to the lowest common denominator. That means that if a part of the team is in survival mode, your team is in survival mode.

The only way to answer that survival mode… Not the only way, but one of the only ways, is to do cross-training so that it becomes everyone’s problem and people can help each other. If you don’t have time to start teaching those people, you’re in survival mode. If you don’t have time to learn, you’re in survival mode. Otherwise, you’re either in learning or self-organization. How do you know if you’re in learning or self-organization? Self-organization is when the team doesn’t really need you to make decisions. They just need you to set the goals.

If a team doesn’t need you to make decisions, you’re probably self-organizing. If the team keeps coming back to you and they need you to make a decision here, a decision there… I’m not talking about signing or approving a document. I’m talking about the team gets stuck, and you’re the only one who can actually shut down the problem. Then that’s an example that the team is missing a skill that you might want to teach them, because if they knew the skill that you already have, they could have solved the problem already.

Even when you know the right things and what to do… getting other people to do those things with you is horribly difficult

Learning through Code Reviews

Derrick:
On your blog, you recommend doing code reviews and taking them seriously, even when times are tough. Why are they key for you?

Roy:
Code reviews are one of the best ways that I’ve seen to share knowledge between people, teach people new tricks, create a fellowship, and at the same time, increase the quality of the code. It really feels like it’s one of those under-utilized things. I think the reason is because a lot of code reviews are being done remotely. Let me explain that. When I say code reviews, I absolutely do not mean code reviews that are done via a comment on GitHub. What I mean is a person maybe sitting just like you and me sitting, or maybe next to each other, looking at the code, thinking out loud, and having a conversation. That’s where the learning comes from.

If you’re doing code review and you haven’t learned anything new or you haven’t taught someone anything new, that code review is almost useless. It costs you more to do a code review that you don’t learn from it. Then, yeah, sure, don’t do it. Don’t even pretend. If you’re going to waste time doing that code review, you better make sure that code review really brings you value. In order to bring you value, you make it a conversation. “I’m looking at this code. Why did you write this class? Why did you do this?”

The reason I want this to be a conversation is because when you write a comment, then a sentence, is usually the culmination of hundreds of thoughts in your head that come down to, “Remove this class,” or “This is duplicate.” Maybe the thoughts in your head are like half a book, that stuff that you’ve learned over the years and the other person needs to learn, such as, “I’ve seen from experience that this has happened many times. Last time that I did it, I had this problem. The way I saw the duplication is because I saw the signatures. I always look at the signatures. When I look at it, they look the same. It’s okay if it’s in properties, but it’s not okay if it’s on singletons.” All this information is just gone, poof, disappears. Then suddenly, you come down to, “This is duplicate.” Then the person doesn’t learn anything. They’re just going to come back to you again and say, “Hey, find me more duplicates, please.” Then you’re back to step one.

Leadership… is a great chance to change the environment, not just bitch about it

Tips for Tech Leads

Derrick:
As part of your book, you spoke to more than 20 team leads about what matters most to them. What are some of the best tips they had?

Roy:
One from Dan North, he talks about actions versus words. He talks about the idea that, as a leader, you’re measured by your actions, not by your words. In fact, if your words and your actions do not match, you’re going to get very little trust. If you’re going to say one thing, and then in a meeting you’re going to do a completely different thing, people are going to stop trusting you. It’s going to be very difficult.

The second is by Bill Walters. He’s saying, “Hey, it’s probably not a technical problem.” I really like this because it also repeats throughout my book. The idea is that, I think, again, I heard it from Gerry Weinberg, and he says, “All technical problems are people problems,” or “All software problems are people problems.” If you trace back, if you use the 5 Why’s method, where you look at a problem, you say, “Why is that?”, and then you continuously ask “Why?” to the next answer five times, you usually get to the root cause. Almost always, the root cause is people.

Derrick:
Did any of the advice or points they raised surprise you?

Roy:
One of them was by Yves Hanoulle. He wrote a thing called the Core Protocols, which is basically a bunch of techniques of how to handle yourself in different environments. I found that very, very refreshing. It’s something I’ve never heard about before. I think that for me, maybe I haven’t had the courage to even try at least a couple of them. That says something, right? Maybe it’s time that I actually do something about that. I choose my battles carefully, but I probably will get to that.

Another thing that was surprising is that… It’s surprising not because I didn’t think it’s true, but I never heard it put that way. Jose Ramon Diaz, he wrote a note called the product is your team. Your team is the product that you’re actually building. Instead of the software that you’re building, the product you’re building is a great team. Obviously what gets created by a great team is a great product. If you think of the fact that what you’re building is not software but you’re building people, it focuses you back into, I like that idea, it goes back to growing people as the main value system, the thing that I always look at, “Am I building a good team? Am I making the team better continuously?”

Common Mistakes of new Tech Leads

Derrick:
What are some of the common mistakes you see new tech leads make?

Roy:
I think one of the most common mistakes is that they tell people what they want to hear instead of telling them what the reality is, because they’re really scared that they want to make a good impression. They say, “Yeah, it’s going to be okay,” or they don’t raise specific flags on specific problems. I think that’s something that that’s a skill, and it takes time. It takes a while to learn that, because it is a bit scary. I think it’s part of our job. We get paid to do good work and to say if there’s a problem.

Another common mistake is that leaders don’t pay attention to whether the group is self-organizing, learning mode, or in survival mode. Those are the three different leadership types that you want to have, because in learning mode, you definitely want to be a coach. You want to teach people. You want to give them time to do it. In survival mode, you usually want to be command-control. You don’t want to start coaching. You don’t have time to coach. You have to get people out of survival mode into learning mode.

If you mix those things up, you have a problem. Suddenly, you’re not really helping the situation. If you have a self-organizing team that already knows how to work, already knows how to do something, and you treat them as if they’re in survival mode and you do micromanagement and command-and-control, you’re going to lose your team very, very quickly. On the other hand, if you go to a team that’s in survival mode and you say, “We’re all working in Scrum now, so I’m going to lock you in the room for two weeks. I won’t tell you nothing of what to do. I’ll just give you goals. I’ll come back in two weeks, and everything’s going to be amazing.”

The answer is probably no, nothing’s going to be amazing. It’s going to be amazingly horrible when you come back, because they won’t have the skills of how to handle themselves. You’re going to open the room. There’s just going to be a bunch of dead people in the room. They won’t know how to feed each other. They will just be lost. They are going to be lost. You don’t want to mix those things up. I see a lot of this. Sometimes it doesn’t make sense. Sometimes it does. You really have to pay attention. That stuff can change from day to day. You have a new project, and suddenly you are back in survival mode. Suddenly you get something you did 100 times before. You’re back in self-organization mode.

Recommended Resources

Derrick:
Can you recommend some resources for developers looking to successfully transition into a tech lead role?

Roy:
There’s this book called Becoming a Technical Leader by Gerry Weinberg. I highly suggest that you read that book. There is a book called Management 3.0 by Jurgen Appelo.

Derrick:
I appreciate you joining us today.

Roy:
Thanks, Derrick. It was lovely talking to you.

by Gareth Wilson at June 17, 2015 10:08 AM

Tim Ferriss

Tim Ferriss


Turning 38-years young… and still not acting my age. (Photo: Sir Garrett Camp)

38! I’ll turn a glorious 38 soon.

It’s going to be a great natal year–I can already feel it. Perhaps it will be good luck for you, too. In this post, I’m giving away a round-trip ticket anywhere in the world.

But back to that strange birthday gift…

Much to the chagrin of my momma-san, I’ve become difficult to buy presents for. Some friends even think I’m impossible to find presents for. Not so. I love handwritten letters, homemade brownies, and–most of all–when people do something nice.

You, dear readers, have a record of being nice and making it count. In fact, you’ve changed thousands of lives with small acts of kindness!

For my b-day in 2010, you all raised more than $100,000 for high-need public school classrooms in the US. More recently, you helped build libraries overseas (See the construction progress on Cambodia, Nepal, and Sri Lanka here, as well as the completed schools in Vietnam).

In lieu of gifts this year, my birthday wish is…

To create the FIRST elementary school in the world with exclusively stand-up desks!

Why?

This is a chance to be part of history.  

THE PROBLEM:
8-18-year olds spend ~85% of their waking hours sitting (Source: Kaiser Family Foundation), and researchers like Dr. James Levine of the Mayo Clinic now compare the health risks of extended sitting to those of smoking.

THE PROTOTYPE THAT COULD CHANGE THE FUTURE:
This is the pilot experiment that could change how schools worldwide are designed. I’m joining forces with Kelly and Juliet Starrett, the brains behind this project and founders of StandUpKids. The goal is to get every public school student in the US at a standing desk within 10 years. This massive goal is achievable if the right snowballs are put in motion now, and this proof-of-concept school is the most important. Media coverage, national attention, political pressure/alliances, etc. can all stem from this. It’s super high leverage.  

Here’s what we’re doing, plus a few things to sweeten the pot:

  1. Join my 38th birthday challenge by clicking here. It’s worth clicking through just to check out the site; Donorschoose.org is one of the most creative non-profits in the world.  This is also their most ambitious project ever.
  • To get your engines started, and to put money where our mouths are: I’ve ready donated $10,000 of my own money, and Kelly and Juliet Starrett have done the same. We have lots of skin in the game.

  • If the spirit moves you, please make a $38 tax-deductible donation (for my 38 years), or whatever you can ($1, $35, $1,000, etc.).

  • 4. We hit $100K and outfit a school that could affect the nation…or even the world! This isn’t hyperbole. This is precisely how movements are started.

    So, to get this party started in force…

    Sweetening the Pot…

    • I’m giving away a free round-trip ticket anywhere in the world that Star Alliance flies, which is just about everywhere. There is no expiration date on the trip, so no rush on deciding where or when to go.

    Here’s how to get it:

  • Leave a comment below telling me what you did (Facebook, Twitter, blog post, e-mail blast, e-mail signature, encouraged employees/friends to do the same, company donation matching, etc.). Measurement of any type gets huge bonus points. This comment must be put up no later than 5pm PST on Friday, June 26th, 2015.

  • Lastly, answer one question at the very top of your comment: “What does education mean to you?”  Put “#EducationMeans” at the very top, followed by your answer.  This is an IQ test in following directions, as we’ll skip entries without #EducationMeans at the top.

  • I’ll pick the winner (if clear), OR my team will pick the top 3-5 promoters, and you’ll vote on the winner of the round-trip.  As always: over 18 only, any taxes are your responsibility, void where prohibited, no minotaurs, etc.

    Fun!

    But the best reason of all…

    Beyond the bribes, you’ll feel awesome about yourself for doing real good.

    Trust me. It feels great.

    Will you pause for a moment and step up, even if for $1? It would mean the world to me. I’ll share updates as I get them.

    Again, here is where you can donate $38, $1, $1,000, or whatever you can.  Just click here.

    Thank you for reading this post. You are all rock stars, and I continue to write on this blog purely because of you.

    Pura vida,

    Tim

    by Tim Ferriss at June 17, 2015 12:23 AM

    June 16, 2015

    Dave Winer

    Uber is not so great

    I posted this on Facebook on Sunday, and sent it to Uber via email. Haven't heard back from them.

    I didn't rent a car in Seattle last week, I thought I'd do better with Uber.

    I took a total of three trips, one of them was pretty bad, and the other two were fine.

    The bad one involved two drivers.

    The first car smelled of cigarettes

    The first car that arrived smelled of cigarette smoke. As a former smoker, I don't like the smell of cigarettes, especially stale smoke. I told the driver that he should probably have smoked outside, not in the car, and I asked if I could get out of the car and get another ride. They charged me for the ride, even though we didn't go anywhere, but I sent an email asking that they issue a credit and they did.

    The driver of the second car drove to the wrong place

    The second car smelled okay, but the driver took me to the wrong address way out in Woodinville. As he was pulling away, after I got out of the car, I realized I wasn't where I was supposed to be and got back in the car, told him about the mistake, and requested that he drive me to the correct address.

    He said that I would have to pay for another trip. I said that was wrong, because I had given Uber the correct address, and verified it, and showed him, over and over. But he seemed to forget each time and kept demanding that I pay. I told him I was going to rate him at one star, he said I shouldn't threaten him, and I said that wasn't a threat, that was my right. So he took me there.

    It was a good thing I had some time to kill at the airport just now, otherwise I probably wouldn't have noticed that he requested that Uber charge me for the extra trip, and they did. Although to their credit, the email did say I could contest it. Of course I did.

    Under normal circumstances I never would have noticed the email with the extra fare, so I decided to write this up publicly. Two bad Uber rides in one day. I haven't used Uber that much, but I've never rated a driver anything other than 5. Two one-star ratings in one day. Not very good.

    Follow-up

    As of Tuesday night, as far as I know I'm still paying for the mistake the driver of the second car made. Haven't heard back from Uber. It's not that much money, but it's kind of disgusting that the guy wouldn't make good in the first place, and then lied about whether he was making good. I gave the driver a 1-star rating so that should help others be warned, but why Uber is holding on to the money? Well, I'm not going to use them again after this experience.

    June 16, 2015 11:42 PM

    Editing APIs for Wikis?

    Blog editing APIs

    One of the things we did in the early blogging days was come up with a web API that made it possible to hook up a desktop editor to a blog. This allowed the full fidelity of the graphic desktop to be applied to blog post editing.

    There were a few iterations of this API before we arrived at the Metaweblog API, which was supported by all the major blogging tools, Blogger, Movable Type, WordPress and my own products, Radio UserLand and Manila.

    Editing APIs for Wikis?

    So if blogs have editing APIs, are there equivalent APIs for wikis??

    I did a little searching and asked a few friends, and so far, I don't think they came together as well as they did in the blogging world, but it seems there would be value creating the link between desktop editors and wiki software on a server. I could hook up an outliner, for example, to the GitHub wiki. Or to Ward Cunningham's new Federated Wiki. If the goal is to get the RSS and blogging worlds and everything that's adjacent to them to hook up with the Wiki world, it seems that editing APIs might a promising place to start.

    So let's figure this out. What's out there to build on, or to serve as prior art?

    June 16, 2015 04:55 PM

    June 15, 2015

    Dave Winer

    Should LeBron be MVP even if the Cavs lose?

    In a word, no. He's a force of nature. A wonderful leader and role model. An amazing basketball player. But not the series MVP.

    As any player will tell you, the competition is about winning, as a team, and if your team doesn't win, you might have been valuable, but you're not the most valuable. Almost by definition.

    So you know where my loyalties lie, I've been rooting for the Cavs because they feel very much like the Knicks, grown up and working right. With leadership, not dabblers and daydreamers. People with their bodies in the actual game, on the court, and driving to victory.

    I love LeBron for making JR Smith and Iman Shumpert better players. I hope the team stays together next year and thereafter, so he can work his magic with their talent. They weren't getting that on the Knicks, obviously. There were times when the Knicks did bring out the spark they both have, basically when they had older players around who could teach them. Melo is not that guy. But Jason Kidd was. And Rasheed Wallace and Marcus Camby, Kenyon Martin, lots of them. The Knicks loaded up on veterans. I didn't understand why then, but I do now, now that I've seen what a difference teaming with LeBron has made. JR is a great technical player but he gets lost in his own mind (famously). And Iman is a very young player, with lots of talent. I could go on and on about this for pages.

    Imho, the obvious choice for MVP is Steph Curry, that is, if the Warriors win, and I want to keep emphasizing that, it hasn't happened yet. It might not turn out that way. All it has to take imho is JR Smith having two halfs like yesterday's first half. At home, in Cleveland that would have made the game turn out the other way, and we would be having a different conversation. With JR hitting his threes, the Cavs would be unstoppable.

    Ooops, I promised not to talk more about the Cavs/Knicks.

    Steph Curry should win, because he was the difference in all the games the Warriors won. It was his spark, the dramatic beautiful shots. He is the most elegant, smooth, smart and lethal point guard I've ever seen. He's poetry in motion, when it's working. But he's also young, and it's easy to get inside his head, and make all that confidence work against the elegance. To be the Curry he must be to win the title, he had to sober up. He has. Now we get to the real part of the competition. It really is not over. Not yet.

    But if it is, and the Warriors win tomorrow, the way they won on Sunday, the creative and interesting choice for MVP, that says something about how the game really works, would be, please hear me out, Andre Iguodala. Until they started him, the Warriors couldn't get around the Cavs on defense, they couldn't get good enough looks for their bomb throwers. With him in the game, they still had a lot of trouble, but they got just enough further for Curry to take his ridiculous circus shots, that happen to go in.

    If "most valuable" means "made the difference" then it really is Iguodala.

    June 15, 2015 04:04 PM

    The People's Browser

    I wrote a tweet yesterday, from the airplane home from Seattle, just to see what would happen. I also posted it on Facebook. It was a conclusion I reached after reading Brent Simmons' latest post, which included a section about HTTP deprecation.

    Here's what Brent said

    "What upsets me about this issue in general is that it’s anti-democratic: it can make writing for the web more expensive and difficult for individuals. As a writer, reader, and open web partisan I dislike everything that shifts power away from people and toward entities with greater resources. What you end up with is corporate speech rather than the voices we know and love and need to hear."

    I've written about this issue, here and here.

    It's about our speech

    In the tweet, people thought I was writing about protecting whistleblowers, or circumventing the control of the entertainment industry, both worthy causes. But what I am protecting is much more fundamental -- the right of the people to use the web as a space to speak their mind without interference from government and corporations. It's as fundamental as the First Amendment of the US Constitution. I've created dozens of websites over the 20-plus years I've been writing on the web that don't support HTTPS and never will. It would be too much work, and too expensive, and would cede control of the content to yet another administrative body. I refuse. You should too.

    Let's study Wikipedia

    I would love to see a study of links emanating from Wikipedia that are HTTP vs HTTPS. The equivalent of an environmental impact study that companies are required to create when they want to alter the environment for commercial purposes.

    Let's see if we can even find the owners of those sites to ask them when they're going to invest the time to support HTTPS. If they don't understand what's involved, offer to teach them, see if they are willing to listen, or can even comprehend what's required of them. How much more will it cost, and do they feel the cost is justified, and will they actually pay? And who will they be paying the money to, that is, who stands to profit from this change?

    I suspect you'll never find a person responsible for most of the content, much less find a plan to migrate to HTTPS. Under the planned deprecation, all those sites will become inaccessible. Why? What's their crime? And what would be at risk at allowing continued access? (Answer, none and none.)

    This has gone too far

    Tech companies are totally out of control, and people are too naive about the use of the Internet, too trusting, too believing of the commercials and PR. Yes we love tech products, but please don't turn that into trust of the people running the companies. They totally do not deserve it.

    Mozilla? Don't make me laugh

    Some have suggested that Mozilla could be the People's Browser. Hah! Mozilla is one of the leaders in the effort to throw away open access to the web. They are the worst of the worst. Don't fall for the PR. They are driving the change, as much as Google is. They should be on the other side, speaking up for and protecting the people.

    Two webs

    The People's Browser very simply, will never require HTTPS. It will work with HTTPS, but it will never not work with HTTP. It would be very simple for Chrome or Firefox to be this browser, by simply making this pledge. Then we won't have to go to all the effort required to route around them.

    Why are they doing this?

    I don't know. I'm shaking my head. I don't want to even think what's kind of obvious, much less say it out loud.

    June 15, 2015 03:02 PM

    Giles Bowkett

    The Future Is Full Of Broken Machines

    John McCarthy created Lisp in 1958. My hope is that Clojure has finally mainstreamed it, although it might be too soon to say. If Clojure fades out, and if you look at the history of Scheme, Common Lisp, and companies like Naughty Dog, it might be more accurate to say that Lisp periodically surfaces outside of academia, but never really achieves escape velocity. Only time will tell.

    But let's assume for the sake of argument that Clojure is indeed mainstreaming Lisp. Even if it's not true, JavaScript is mainstreaming functional programming, which is pretty close.

    If that's the case, it's kind of horrifying: the optimistic interpretation is that Lisp took 49 years to reach the mainstream (because Clojure was released in 2007).

    Brendan Eich came to Netscape because they told him he could put Scheme in the web browser. So we could stretch the definition and use JavaScript's 1995 release date instead. But we'd be seriously fudging the numbers, and we'd still have Lisp making a 37-year voyage from new paradigm to mainstream acceptance.

    One of the classic books of the tech business is Geoffrey Moore's Crossing The Chasm, which is all about how to transition a product from the early adopters to the mainstream. If you buy the narrative that all programmers are eager explorers of the future, it's pretty ironic that a programming language should have such a hard time making this transition.

    But let's be honest here. Most programmers are very conservative and tribal about their toolsets. And with good reason: programming any particular language requires a lot of specialized knowledge and experience. Once you get good enough at something intricate and challenging that you can charge a lot of money for it, you usually want to stick with it for a while. If you dive into a Clojure code base after years of writing C, it might be uncomfortable, awkward, and extremely unprofitable.

    There's also something paradoxically both intimate and mechanistic about the way that wrapping your head around a programming language can change the way you think, and thus, to some extent, who you are. Learning your second programming language thoroughly and well is a lot harder than your fifth or your sixth. Programmers risk a phenomenon of paradigm freeze, similar to the phenomenon that psychologists have identified as "taste freeze" in music:
    From around the age of 15 years old, music tastes begin to mature and expand as listeners increase the diversity of the music on their playlists.

    Tastes appear to change most quickly through the teenage years until the age of about 25 when this sense of discovery slows and people move away from mainstream artists.
    I even saw a Douglas Crockford keynote where he said that the only way you can advance a new programming paradigm is by waiting for the entire current generation of programmers to retire or die.

    Let's pretend that we have all the cynicism and despair that anyone would get from working at Yahoo for a long time, and agree with Mr. Crockford, for the sake of argument.

    It would stand to reason that there must be new programming paradigms today that have not yet crossed the chasm.

    I believe that this is probably true, and I have two specific examples. The irony is that both of these paradigms are embedded in technologies we all use every single day. Yet I would not be surprised at all if they remained widely misunderstood for the next 50 years, just like Lisp did.

    One of them is git.

    You Probably Don't Understand Git (For Large Values Of You)


    git's a completely decentralized technology, which requires no master branch whatsoever (master is just a name).

    But people typically treat git as a completely centralized technology which depends absolutely on its center, GitHub.

    You've probably heard some variant of this story before:
    Panda Strike's CEO, Dan Yoder, told me a story about a startup where he served as CTO. GitHub went down, and the CEO came into his office, saying, "we have to move everything off GitHub!" He was upset because no programmer could do any work that day. Except, of course, they could. You choose one person's repo as the new, temporary master version of master, fire up sshd, and replace GitHub with your laptop until their servers come back online.
    One time, I worked at a company which was nearly all remote, with a small office in one city but plenty of programmers in other cities. Soon after I joined, we all spent a few days hacking and hanging out in a cabin in the woods. Our WiFi was very unreliable, so we were unable to reach GitHub. We just used gitjour, which wraps Bonjour, Apple's Zeroconf networking tech, to host and advertise git servers over small local wireless networks. In other words, one person said "I'm the canonical repo now," and we all connected to their computer.

    The point is, git doesn't depend on GitHub. GitHub adds value to git. But to most people, the major difference between git and Subversion is that there's a web site attached to git.

    On Panda Strike's blog, I went into detail about this:
    GitHub is also hierarchical even though git is flat. If GitHub only added a center to git, it would have commits flow to the center of a web of repos. But that's not how it works. On GitHub, pull requests have to flow upwards to attain lasting impact.

    It's this:



    Not this:

    Using GitHub adds a center and a hierarchy to git. These are usually beneficial. But, as I explore in that blog post, the added-on center and hierarchy become a problem when you have a project with a thriving community but a disinterested creator.

    And the real downside of this tradeoff isn't that edge case. The real downside of treating git as if it were centralized is that lots of people assume that it is centralized. To a lot of people, this entirely new paradigm of distributed version control is basically just Subversion with a web site and a smiling cartoon octopus/cat beast from the island of Dr. Moreau.

    You Probably Don't Understand HTTP Either


    HTTP has this problem too. Not only that, HTTP's had this problem for more than twenty years. People who don't understand HTTP are constantly reinventing features that the protocol already has, and moving those features from the protocol layer to the application layer in the process.

    Some examples:
    But the biggest and most egregious examples would be media types, the POST header, and, of course, REST.

    Media types matter because HTTP has a type system. It's based around the fundamental, important, and seemingly forgotten idea of hypermedia. This idea is so powerful that it basically puts an everything-is-an-object system like Smalltalk or Hypercard around the entire planet; but it's so frequently under-exploited that it's almost just a footnote. (But a footnote which can make your API traffic incredibly fast.)

    With POST, the situation's improving, but for decades, POST was the go-to HTTP verb for nearly everything a Web app ever did. Ironically, however, POST was intended as a footnote. HTTP's basically a giant, globe-spanning key/value store, but just in case, the spec included POST for any kind of random operations that weren't covered in the primary use cases of GET, PUT, and DELETE.
    The core operations for a key-value store are get, put, and delete. As you'd expect, each of these correspond to well-defined HTTP verbs. And by well-defined, I mean that they're more than just window-dressing to indicate intent. For example, a client might cache the response to a GET request exactly because it's defined to allow that.

    But HTTP includes a fourth verb, POST, which provides for cases where strict key-value store semantics don't suffice. Rather than take the pedantic tack of insisting that everything fit into a single abstraction, HTTP gives you POST as a fallback.

    Unfortunately, for historical reasons, this led developers to misunderstand and overuse POST, which, in turn, contributed heavily to the confusion that surrounds HTTP to this day.
    In practice, most web developers have looked at POST as the mechanism which enables RPC on the web. "If I want to prompt the server to perform an action of any kind, I use POST." This meant that a huge number of HTTP requests over the past twenty-plus years could have used HTTP verbs to identify their purposes and intents, but instead had the application layer figure it out.

    Even systems like Rails, whose developers realized that they could use HTTP verbs for this purpose, lost track of the basic idea that HTTP was a big key/value store. Instead of recognizing that PUT maps exactly to the act of putting a new key in a hashtable, they chose randomly, with no obvious rationale, to arbitrarily consider PUT equivalent to the "update" in CRUD, and POST equivalent to CRUD's "create."

    Using the application layer to handle protocol-level information makes web apps slower to run, and more expensive to build and maintain. If we could total up the dollar value of this misplaced effort, it would be quite a lot of money. That's true also for the example of rebuilding Basic Auth by hand on every site and app since day one.

    As for REST, it's a huge topic. For now, just understand that this mountain of errors we're looking at is really just the tip of an iceberg.

    Superset The Dominant Paradigm


    To paraphrase William Gibson, the future is already here, it's just not widely recognized. People in general find it a lot easier to put a new, unfamiliar thing in a familiar category than to wrap their heads around a new idea, and that's true even when the new idea doesn't really fit in the category they choose for it. Designers even do this on purpose; for instance, it's not an accident that getting on an airplane feels a lot like getting on a train, and the reason isn't because trains are necessarily great models for organizing transit. They're good, but that's not the reason. The reason is that when flight first became a widespread technology, it scared the shit out of people. Designers made it look familiar so it would feel safe.

    In 2008, GitHub basically did the same thing. Git's fundamentally a functional data structure, but that sales pitch will only work for a few very unusual people. "Imagine if Subversion could handle many more branches at a time" is a much easier sell. Likewise, treating hypermedia like a bunch of remote procedure calls was just easier for a lot of people.

    But here's where I disagree with Mr. Crockford: I believe that the idea that everybody has to understand a paradigm, for that paradigm to matter, is itself an outdated paradigm. After all, both HTTP and git have been wildly successful despite consistent and incredibly widespread misuse.

    Maybe the key is just to superset some existing paradigm, so that the late adopters can use their old paradigms, while early adopters use their new paradigms, all within the same technology. This approach certainly worked for JavaScript, and it might even be the secret sauce behind Git and HTTP's success stories too.

    by Giles Bowkett (noreply@blogger.com) at June 15, 2015 02:02 PM

    An Annoyance: "Virtuoso Mixer Players"

    When a radio interviewer asked deadmau5 about his disrespect for DJing as an art form, deadmau5 said he didn't know any virtuoso mixer players.



    But anybody who knows anything about dub music knows that dub is all about virtuoso mixer players.



    Turntablism is also all about virtuoso mixer players.



    If you don't know of any virtuoso mixer players, then you don't know about Underworld - one of the greatest electronic acts of all time - and you don't know about dub or turntablism - two entire genres which have both shaped electronic music.

    deadmau5 is an interesting producer and his live shows have tremendous style. But he talks a lot of shit, and he doesn't always know what he's talking about.

    by Giles Bowkett (noreply@blogger.com) at June 15, 2015 10:17 AM

    John Udell

    After Yahoo Pipes: Back to square one?

    I had long expected the Yahoo Pipes end-of-life announcement, but it was still sad to finally read it. Wiring the Web, as Pipes and newer services like IFTTT and Zapier do, will continue to be a great way to get things done.

    Last week, for example, I noticed traffic to a Web server where I'm running a soon-to-be-retired prototype of an Atom feed for our annotation service. The next day I found out it was a partner who's using Zapier to pull the data into a tracking system. Cool!

    [ Automation for the people: The programmer's dilemma. | Get a digest of the day's top tech stories in the InfoWorld Daily newsletter. ] IFTTT Slack iOS jonudell.net

    I've been poking around with IFTTT and Zapier too, using them to connect our Atom feeds to apps, like Slack, that in turn can send notifications to mobile devices. This is silly, simply a way to try out how it'll feel when we can do it more directly.

    To read this article in full or to leave a comment, please click here

    by Jon Udell at June 15, 2015 10:00 AM

    June 14, 2015

    Giles Bowkett

    Mad Max vs. The Babadook: Australian Feminist (And "Feminist") Movies

    Two movies. Both from Australia. Both with feminist themes.

    Mad Max has a male director, and The Babadook has a female one.

    Mad Max has a tumblr about how feminist it is. But in terms of story mechanics, only one of the female characters takes actions or makes decisions which push the story in any direction at all. And that female character sports a masculine look.

    I knew a screenwriter once who said that not every actor gets to play a character. What an actor calls a character only counts as a character in screenwriting terms if they play a role in shaping the story. Some actors just play window dressing, situations, punchlines, or MacGuffins. He was talking about movies like Mad Max.

    This "feminist" movie is packed to the gills with women who act as props. They take a backseat for almost the entire film. I'm not even speaking figuratively. There is a backseat, and they sit in it.

    Story is what makes people give a shit. For the first hour of Mad Max, I thought I would be coming back the next day to see it three or four times in the theaters. After the first hour, I was bored and ready to leave - especially since the second hour is basically just a repeat of the first hour, but with motivations that make much, much less sense.

    I heard a snort of contempt from someone else in the audience when Imperator Furiosa did her weird little "we're not white people" tribal gestures with her long-lost fam. A dude somewhere behind me barked an aggressive, approving laugh when Max told Furiosa that she was the only woman who could get in the truck. You lose the audience, you have nothing.

    Meanwhile...

    The Babadook centers on a woman, and it puts that woman in conflict with her sister, her sister's (female) friend, her niece, a little old lady who lives next door, and a female bureaucrat. These female characters, in actor terms, are female characters in screenwriting terms as well. They make the story happen.

    It's a horror movie, and it's scary as fuck. It's also emotionally moving; because there's so much story, there's also a ton of giving a shit.

    If you're a female actor and you got a role in Mad Max, it's not much different than working on the average rap video. You're going to wear revealing clothing. You'll mostly just be standing around looking pretty the whole time - but this time, you're doing it for feminism.

    The kind of feminism where the only woman who actually matters in the entire movie dresses like a man. Backed with the kind of story that would never persuade anyone who didn't already agree.

    Meanwhile, if you're a female actor and you got a role in The Babadook, you're going to have to work, because your role affects the story.

    And the worst misogynist could watch this thing, feel sympathy for this woman, and want her to succeed.

    I know a lot of people are starved for feminist semiotics in cinema, yet for some reason they won't satiate that hunger by seeing any movies except for obvious Hollywood stuff. They're happy about Mad Max, and I'm glad they got at least a taste of what they wanted. But if you want the real thing, you don't have to look very hard.

    If you're hungry for feminism in movies, you should know that The Babadook is a tomato, and Mad Max is the kind of ketchup they make out of corn starch and red food coloring.

    One of these movies is an awe-inspiring chase scene, punctuated by terrible dialog, and followed up by a crappy remake of its own first hour. As a chase scene, it's a work of genius. If it ended after the first hour, it would be the best short film ever made.

    But the other one is an actual movie.

    by Giles Bowkett (noreply@blogger.com) at June 14, 2015 09:15 AM

    June 13, 2015

    Dave Winer

    An exciting west coast trip

    I'm winding up a west coast trip that took me to Portland and Seattle over the last week. Lots of interesting meetings, and along the way a number of developments that inspire new thinking.

    Allen & Ward

    I spent two days in Portland as the guest of Allen and Rebecca Wirfs-Brock. The purpose of the trip was to get me together with Ward Cunningham, the guy who invented the wiki. He has a fascinating story, and because he's not much of a writer himself, I'm not sure if it's been told. He and I think and work a lot alike, and have been working in parallel on flip sides of the same idea since the mid-90s, without ever meeting (indicating that there may be a conference missing in the tech world). We're already working on a couple of projects and thinking about a bunch more. The goal is to connect our work in interesting new ways. And since we both abhor lock-in, and love working with other developers, the connections will be open, and our products subject to replacement. That is one way new standards are developed.

    Allen Wirfs-Brock works on a different kind of standard. He's the editor of the new JavaScript spec. What a thrill to meet someone in his position. Me, the JavaScript newbie, got to ask the super-expert how to do the things I want to do. He knows. Allen and Ward have both been around even longer than I have, so the stories were fantastic.

    One thing I came away with is a wish that I had made this trip, and met Ward, a long time ago. My life would have been vastly different, for the better.

    Changes at Twitter

    On the train Thursday from Portland to Seattle, Twitter announced an end to the 140-char limit for DMs, and also announced that CEO Dick Costolo was stepping down, being replaced, at least in the interim, by Twitter founder Jack Dorsey.

    I'm glad they got rid of the 140-char limit, at least in DMs.

    I have had a chance to think, if I was the new czar of Twitter, what I would do, and it would be this. I'd list all the limits for users and devs, and one by one, erase them. I would move Twitter into position to be the ultimate open platform for realtime communication. I would make some unretractable commitments to developers, by releasing lots of the basic Twitter technology as open source, so it could be immediately federated. It might take some time to do it well, and we would take the necessary time. It would guarantee that we'd always have the highest performance, most reliable notification system, or we'd be replaced. Honestly, I'd bet that over time we would be replaced. But the Internet still needs an identity system. And for that, I'd charge users a small yearly fee to maintain an identity that could participate in the global network that Twitter would now define. That would cut back on a bunch of initiatives, so some of the current Twitter employees would go on to start new companies. I'd invest in them, so we could participate in their upside. This would prepare Twitter for mid-life. It's no longer a startup. And now it's time to serve as a true coral reef, as an operating environment, as an organization, and as a bank account. I know this is a radical re-shaping, and it may only be possible if Twitter is acquired, and basically taken private, and I wouldn't have a problem with that as long as one of the terms of the deal is that all this would happen. The idea is to get Twitter back on track to being globally significant. To realize the potential it had when it was a startup almost ten years ago.

    If the acquirer were Google, btw, I'm pretty sure they'd be happy to go this route, because no matter what their future is tied directly to the future of the open web, and the open web is suffering because of all the silos. One of them is Twitter. Desiloizing Twitter would be a brilliant move, it would strengthen the open web, create vast new developer opportunities, and investment opportunities for the new owners. Google, of course, has much more cash than Twitter, and already realizes that it needs to diversify. Here's a great way to add fuel to the fire.

    Of course no one is hiring me to run Twitter, so this is all a fancy dream. But it's fun to speculate!

    Apple and RSS

    One more idea then I have to go.

    Yesterday I, and a bunch of other bloggers, got an email from Apple saying they wanted to use our RSS feeds in their new Apple News product. There were a few conditions, very reasonable, and an easy opt-out. I was very happy to see this, and glad to have this blog participate.

    Earlier in the week when they announced Apple News, it appeared as if we would have to convert our feeds to conform to Apple's guidelines. I wasn't planning on doing that. But it's great that Apple is accepting RSS as-is, and making that support very public.

    Now I think of people who thought there was no reason to have a blog and an RSS feed. To get this distribution, apparently, you need to be here. Apple just gave the open web a big boost. A big surprise, and much appreciated.

    June 13, 2015 08:28 PM

    Tim Ferriss

    TF-StitcherButton

    The Tim Ferriss Show with Bryan Johsnon

    Bryan Johnson is an entrepreneur and investor. He is the founder of OS Fund and Braintree, the latter of which was bought by eBay in 2013 for $800 million in cash.

    Bryan launched OS Fund in 2014 with $100 million of his personal capital to support inventors and scientists who aim to benefit humanity by rewriting the operating systems of life. In other words: he fuels real-world mad scientists.

    His investments include endeavors to cure age-related diseases and radically extend healthy human life to 100+ (Human Longevity), replicate the human visual cortex using artificial intelligence (Vicarious), mine an asteroid (Planetary Resources), reinvent transportation using autonomous vehicles (Matternet), and reimagine food using biology (Hampton Creek), among others.

    Our conversation includes his rags to riches story, his philosophical hardwiring, negotiating/sales tactics, and even parenting. We cover a ton of ground with a fascinating and deep mind.

    Enjoy!

    TF-ItunesButtonTF-StitcherButton

    Do you enjoy listening to world-class entrepreneurs?  If so, you might enjoy my conversations with Peter Thiel. He co-founded PayPal in 1998, which was sold to eBay for $1.5 billion. He was also the first outside investor in Facebook (!) and has since created another billion-dollar+ startup called Palantir. Stream our conversation below or right-click here to download:



    This episode is sponsored by Athletic Greens. I get asked all the time, “If you could only use one supplement, what would it be?” My answer is, inevitably, Athletic Greens. It is your all-in-one nutritional insurance. I recommended it in the The 4-Hour Body and did not get paid to do so.  Get 50% off your order at Athletic Greens.com/Tim

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Give it a test run…

    QUESTION(S) OF THE DAY: Do you have a story of an untested assumption that held you back? How did you identify it and change your behavior? Please let me know in the comments.

    Scroll below for links and show notes…

    Selected Links from the Episode

    Human Longevity | Ginkgo Bioworks

    Show Notes

    • Gasoline bombs, baseball cards, and deconstructing high school power structure [2:00]
    • How Ecuador and cell phones helped Bryan as an entrepreneur [8:20]
    • From broke and unemployable to a record-setting sales person [12:35]
    • The critical failure point for Bryan’s real estate company [16:50]
    • What to look for when hiring sales people [18:30]
    • How long until a computer can identify trustworthy people? [21:00]
    • The transition from sales person to founding Braintree [22:35]
    • How to build a technical team without being a technical founder [25:30]
    • The three main goals Bryan had in mind when founding Braintree [27:05]
    • On deciding to pivot the direction of the first profitable company [30:40]
    • Appreciating Ernest Shackleton and the “Shackleton sniff test” [33:40]
    • Are you glad that you got an MBA? [35:15]
    • On firing the rocket ship that was Braintree and market targeting for re-broadcasting [38:45]
    • Breakaway moments, primary competitors, and convincing big companies to use Braintree [42:20]
    • What it means to code to the Application Programming Interface (API) and the growth potential if done well [45:00]
    • Keys to building a workplace loved by employees [47:45]
    • Why storytelling was critical for cultivating a great company culture [52:15]
    • On becoming a pilot, the process, and estimated costs  [58:30]
    • How Bryan Johnson defines “success” [1:00:45]
    • The OS Fund, why it exists, and how to think on the “operating system level” [1:02:10]
    • On the moral questions of advanced technology at scale [1:07:20]
    • Challenging assumptions and the story of five monkeys sprayed with cold water [1:14:30]
    • How Bryan Johnson unpacks feelings of overwhelm [1:18:35]
    • The historical figure Bryan Johnson most identifies with [1:22:10]
    • Entrepreneurs who Bryan Johnson admires for their aggression [1:26:30]
    • What is an entrepreneur? How does one develop entrepreneurial characteristics? [1:28:30]
    • Rapid Fire Questions: Most gifted books, billboards, and advice to his 30-year-old self [1:32:00]
    • Non-obvious traditions to hold with your kids and common problem points when parenting [1:35:55]

    People Mentioned

    by Ian Robinson at June 13, 2015 03:18 AM

    Dave Winer

    Scripting News in Apple News

    I just got a very nice email from Apple saying they are including Scripting News in Apple News, and they offer me a chance to opt-out. But if I don't mind (of course I don't) I don't have to do anything. Delighted that they have accepted the spirit of RSS, at least so far.

    June 13, 2015 12:40 AM

    June 11, 2015

    Lambda the Ultimate

    Self-Representation in Girard’s System U

    Self-Representation in Girard’s System U, by Matt Brown and Jens Palsberg:

    In 1991, Pfenning and Lee studied whether System F could support a typed self-interpreter. They concluded that typed self-representation for System F “seems to be impossible”, but were able to represent System F in Fω. Further, they found that the representation of Fω requires kind polymorphism, which is outside Fω. In 2009, Rendel, Ostermann and Hofer conjectured that the representation of kind-polymorphic terms would require another, higher form of polymorphism. Is this a case of infinite regress?

    We show that it is not and present a typed self-representation for Girard’s System U, the first for a λ-calculus with decidable type checking. System U extends System Fω with kind polymorphic terms and types. We show that kind polymorphic types (i.e. types that depend on kinds) are sufficient to “tie the knot” – they enable representations of kind polymorphic terms without introducing another form of polymorphism. Our self-representation supports operations that iterate over a term, each of which can be applied to a representation of itself. We present three typed self-applicable operations: a self-interpreter that recovers a term from its representation, a predicate that tests the intensional structure of a term, and a typed continuation-passing-style (CPS) transformation – the first typed self-applicable CPS transformation. Our techniques could have applications from verifiably type-preserving metaprograms, to growable typed languages, to more efficient self-interpreters.

    Typed self-representation has come up here on LtU in the past. I believe the best self-interpreter available prior to this work was a variant of Barry Jay's SF-calculus, covered in the paper Typed Self-Interpretation by Pattern Matching (and more fully developed in Structural Types for the Factorisation Calculus). These covered statically typed self-interpreters without resorting to undecidable type:type rules.

    However, being combinator calculi, they're not very similar to most of our programming languages, and so self-interpretation was still an active problem. Enter Girard's System U, which features a more familiar type system with only kind * and kind-polymorphic types. However, System U is not strongly normalizing and is inconsistent as a logic. Whether self-interpretation can be achieved in a strongly normalizing language with decidable type checking is still an open problem.

    June 11, 2015 06:45 PM

    Fog Creek

    dev.life – Interview with Tomomi Imura

    In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

    Today’s guest is Tomomi Imura, Senior Developer Evangelist at PubNub, who previously worked in mobile development roles for Yahoo! and Palm. She’s an Open Web advocate and writes about HTML5, CSS, JS, UX, tech events and gadgets on her blog. However, unintentionally she’s perhaps best known for creating the HTTP Status Cats.


    Tomomi Imura
    Location: San Francisco, CA, US
    Current Role: Senior Developer Evangelist at PubNub

    How did you get into software development?

    My first “computer” was Canon’s low-cost MSX machine in the 80s. While all other kids were playing games on Nintendo, I was more into programming BASIC, well, sort of. What I did was I manually type in some code samples from books because copy-paste wasn’t available.

    However, I then completely lost my interest in programming. I started getting into music and playing guitar, and didn’t even touch a computer until I re-discovered some geek fun after I got an Apple Performa later in the mid-90s.

    Around that time, I taught myself how to code HTML to create a website dedicated to Mac communities. My moniker, @girlie_mac, originates from my first overly pink website called “Girlie MacIntosh”.

    I never formally studied any Computer Science while I was in college. I actually studied Biology, and my first professional job wasn’t related to computers either. I was a researcher at an Environmental Microbiology lab. But I never stopped updating my website because of its popularity and eventually I joined an e-learning (or edTech, in 2015 terms!) startup as a Web Developer.

    Ever since, I have been developing for web and mobile web, including web-based operating systems for mobile phones! (remember Palm webOS?). Lately though I have shifted my role to a developer evangelist.

    msx (1)

    Tell us a little about your current role

    My current gig is at a real-time data stream network startup, called PubNub. Just like UX designers are trying to create great user experience for apps and services, I am working to achieve great developer experiences with our APIs. I do this by providing guides and tutorials with easy-to-follow code samples and diagrams, and occasionally giving talks and workshops at conferences. I am always thinking about the most efficient and effective ways to make complicated materials into something developers can follow easily. I write tutorials like “How to create a collaborative HTML5 canvas drawing app” and “Internet of Things 101 with Raspberry Pi”. Right now, I am helping summer interns to create more Internet of Things projects, using Arduino, Raspberry Pi, etc.

    When are you at your happiest whilst coding?

    When I have the Eureka moment. Sometimes I struggle for hours to solve one thing, and then all of sudden the answer comes from nowhere (not even from StackOverflow!). This can be from a dream, but usually changing my perspective is the way to have the moment.

    devtools (1)

    What is your dev environment?

    I use a MacBook Air with Sublime for coding and Adobe Photoshop and Illustrator for graphics. I use a Wacom Intuos tablet when I work on graphics and diagrams.

    My must-have tools include browser dev tools, such as Chrome DevTools. They are something I definitely cannot live without as a front-end developer. I can inspect, debug, tweak styles, view local DB, etc. I can’t imagine how I could work without the tools.

    I also love Evernote and Skitch – they come in really handy for note taking. I use them whenever I have ideas for my next projects etc, even when I am away from home/office. I can write them down and attach photos on Evernote anywhere, also I can annotate the photos with Skitch.

    I code sitting, no music, nothing special. My problem is I am always snacking while working. I have gained 8 lbs recently…

    What are your favorite books or resources about development?

    My fave is MDN, Mozilla Developer Network, whenever I need to search web APIs and JavaScript references. Also, this is not a dev tool, but I use Creative Commons Search a lot when I need some funny cat photos, or anything that may be useful for my blog and presentation slide decks.

    httpStatusCat (1)

    What technologies are you currently trying out?

    I’ve started getting into hardware hacking these days. I got myself a LilyPad Arduino at Maker Faire, so I really want to create some fun wearables!

    When not coding, what do you like to do?

    Sitting all day coding gives me back pain so I try to Yoga often. I sometimes take outdoor Yoga classes in Golden Gate Park, especially when the infamous fog (“Karl the Fog”) is away. I must enjoy the rare sunlight whenever I can!

    Otherwise, I am making more cat memes.

    What advice would you give to a younger version of yourself starting out in development?

    Don’t hesitate to ask people dumb questions. Your questions may not be so dumb after all.

     

    Thanks to Tomomi for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

    Recent dev.life Interviews

    Chris
    Chris Hartjes
    Paul Jones
    Paul M. Jones
    Michael Fogus
    Michael Fogus
    Casey Muratori
    Casey Muratori

    by Gareth Wilson at June 11, 2015 09:04 AM

    June 10, 2015

    Axis of Eval

    Grokking Reactive Demand Programming

    TL;DR: RDP is an exciting declarative model of how computational processes (behaviors) are connected by continuously updating values (signals) to effect changes on storage and external state (resources).

    I've come a bit closer to understanding David Barbour's Reactive Demand Programming model, and this has confirmed my previous hunch that RDP is one of the most interesting systems designs since Unix. If you're looking for new, better ways to structure dynamic, interactive applications, I strongly recommend checking out RDP.

    I would call RDP an orchestration model, since it cares about how you connect and assemble components of your app, and gives you a lot of freedom in what these components do and how they interact. This also fits with David's description of an RDP application as "a complex symphony of signals and declarative effects orchestrated in space and time".

    In terms of Unix, RDP's behaviors correspond to processes, signals correspond to pipes, and resources correspond to storage and other external, stateful things.

    Signals (pipes, channels)

    A signal continuously delivers a potentially changing value. The current implementation always updates the complete value, but RDP doesn't rule out diff/patch-based signal updates, to model e.g. a large set as a signal value.

    In addition to these simple signals carrying a single value, there are also compound signals, such as (x :&: y) which represents the concurrent, asynchronous product of signals x and y, IOW a signal representing two independently updating signals. Analogously, (x :|: y) represents a disjoint sum of signals, with either x or y being active at any given point in time.

    A signal is either active (carrying a value), or inactive (disrupted). Application-level errors have to be modelled as part of the value, there is no "stderr".

    Behaviors (processes, computation)

    A behavior won't do anything until you place a demand on it. You place a demand on a behavior by applying an input signal (the demand) to it; the behavior will produce an output signal for the duration of this application.

    Multiple demands can be placed on a behavior at the same time. The behavior can either reply to each input signal with a different output signal, or with the same output signal, depending on the purpose of the behavior. For example, a "calculator" behavior may take N input signals with expressions like "1 + 2" and "3 * 5" and deliver a distinct output for each input; on the other hand, a "sum" behavior may take N input signals carrying a number and produce a total sum as the output signal, which would be the same for all inputs.

    Behaviors can be composed into dataflow networks. A simple composition is the pipeline behavior, b1 >>> b2: the input signal of this pipeline behavior will be processed by the behavior b1; b1's output signal becomes the input signal for behavior b2; and finally, b2's output signal becomes the output of the whole pipeline behavior.

    The Sirea Haskell implementation of RDP comes with other behaviors such as bdup, that copies a single signal into both branches of a :&: product, for creating more complex networks of signals and behaviors. There are also primitives like bfirst and bsecond for running different behaviors against the branches of product signals, and bfmap for applying ordinary Haskell functions to signals.

    Resources (storage, external state)

    RDP doesn't say anything about state, so it has to come from the outside. Access to stateful resources such as filesystems is abstracted through behaviors: to access a filesystem you use a behavior like readFile "foo.txt" that continuously delivers the contents of the file "foo.txt" as output signal.

    Creating new resources in RDP is impossible, so resource discovery idioms are used: for example, to "create" a file, you use a UUID as its name, and it will be automatically created the first time you write to it.

    I hope this has been helpful. For further reading, check out the extensive README of the Sirea RDP implementation, and David Barbour's blog.

    by Manuel Simoni (noreply@blogger.com) at June 10, 2015 01:59 PM

    Giles Bowkett

    Browser MIDI Is About Hardware As Much As Music

    You can use MIDI to make music in your web browser, and that's going to open up a lot of new possibilities.

    But it isn't just about the music. There's such a huge range of MIDI controllers available that the web browser just became a perfectly viable platform for very basic embedded systems. One major, important trend in music software is external controllers which completely replace the computer as a user interface.

    With the Traktor S2, released about four years ago, you didn't need to look at your computer very much:



    With the Traktor S8, you don't need to look at your computer at all:



    By contrast, here's somebody using MIDI controllers with loopjs.com to make music in the browser:



    They're looking at their computer while they do it. But they won't have to for very much longer. Web companies will discover the same thing that musical instrument manufacturers have learned. And computers are shrinking rapidly.

    by Giles Bowkett (noreply@blogger.com) at June 10, 2015 09:12 AM

    June 09, 2015

    Tim Ferriss

    Tim Ferriss

    This short (<5 minutes) video will teach you how to triple your reading speed in less than 20 minutes. It works nearly immediately, and there is zero loss in comprehension.

    No voodoo, no pseudoscience — just two tricks for optimizing eye movement.

    Some of you learn better with text, and some of you learn better with video. As one commenter who watched the above video put it:

    “Tim, thanks so much for this video. I read your blog post about this like four times without being able to get it. With a video, it’s much easier.”

    Have fun, and I’d love to hear your results in the comments.

    If you enjoy this, you might also like my posts on rapid language learning, or my interview with champion memory competitor, Ed Cooke. You can stream the latter below:


    by Tim Ferriss at June 09, 2015 04:43 PM

    Mark Bernstein

    Posthuman Transformations

    Just received a copy of Alexandra Glavanakova’s Posthuman Transformations: bodies and texts in cyberspace. It’s a study of three works: Pat Cadigan’s Synners, Shelley Jackson’s Patchwork Girl, and Talan Memmot’s From Lexia To Perplex. Fascinating.

    June 09, 2015 04:39 PM

    1177 B.C.: The Year Civilization Collapsed

    By the 12th century BC, late Bronze-Age civilization had climbed many technological summits. People had cities, trading fleets, and caravans. People had built tall towers, elaborate palaces, complex bureaucracies and smoke-filled taverns. People had pickles, onions – our word “shallot” comes from the Canaanite city Ashkelon – and sesame-seed buns: “sesame” in English is a loan-word from Akkadian.

    But in 1177, give or take a few years, everything fell apart. Egypt, Mycenae, Knossos, Babylon, Hattusa, Ugarit, Troy: – just about everywhere you look, there are fires and wars and devastation and disaster. Centuries would pass with people telling stories about the age of heroes, the age before the end of Western civilization.

    The cause of the disaster has been extensively discussed in recent decades, and Cline nicely summarizes what we know. A rash of earthquakes didn’t help at all. A shadowy group of warrior-migrants called the Sea Peoples caused plenty of havoc; it’s odd that we know so little about them, but then, we know shockingly little about the Huns and the Huns are 1,600 years closer to us. Ideology may well have played a role: people everywhere may have been getting tired of the whole business of palace culture, or merchant-adventurers (or pirates) may have cut into the profit margins that kept those palaces running. Climate change may have been a factor. Commodity shocks may have wrecked the economy; the entire word depended on one mine for weapons grade tin. There are signs of fiscal turmoil in Greece, where Mycenae played a pivotal role in international trade. The Sea Peoples might have been Greek or Italian. Perhaps the first Grexit brought down a multinational economy already weakened by climate change, ecological mistakes, financial shenanigans and social upheaval.

    June 09, 2015 04:39 PM

    Fog Creek

    Going Beyond Code to Become a Better Programmer – Interview with Pete Goodliffe

    .little {font-size: 75%}
    Going Beyond Code to Become a Better Programmer – Interview with Pete Goodliffe

    Looking for audio only? Listen on

    In this interview with Pete Goodliffe, author of ‘Becoming a Better Programmer‘, we dive into issues that go beyond code and separate the good from the great developers. We cover things like attitude, communication skills, managing complexity and what you can do to learn more and keep your skills up to date.

    Content and Timings

    • Introduction (0:00)
    • About Pete (0:23)
    • A Great Developer’s Attitude (0:49)
    • Write Less Code (2:00)
    • Communicating Effectively (3:10)
    • Handling Complexity (4:24)
    • Keeping Your Skills Up to Date (7:07)
    • Recommended Resources (8:27)

    Transcript

    Introduction

    Derrick:
    Pete Goodliffe is a programmer and software development writer, perhaps best known for his software development book, ‘Code Craft’. He speaks regularly at conferences on software development topics and recently published ‘Becoming a Better Programmer: A Handbook for People Who Care About Code’. Pete, thank you so much for joining us. Would you like to share a bit about yourself?

    About Pete

    Pete:
    Sure. I’m a geek. I’m a developer. I like to say I’m a conscientious coder, making the world better one line of code at a time. I am a regular magazine columnist. I’ve been writing a column for more than 15 years now, which is probably some kind of record, I suspect. My day job, I’m a coder. I work in a really awesome team making fun stuff. I’m a musician and I get the opportunity to write code for musical instruments.

    A Great Developer’s Attitude

    Derrick:
    In the book, Becoming a Better Programmer, you say the real difference between adequate programmers and great programmers is attitude. What are the characteristics of a great programming attitude?

    Pete:
    The standout difference between the really good coders that I’ve worked with and the guys that aren’t so great, is attitude. It’s not a hand-wavey thing. I’ve worked with guys who know technology and who know the idioms, and how to do all this stuff. If they don’t have the right attitude they’re just not effective programmers and they’re not great guys to work with. The kind of stuff I’m talking about here, is humility. You don’t want to work with guys who think they know it all but don’t. Being humble is the key thing.

    It doesn’t mean that’s an excuse to not know stuff, but just not believing that you’re better than you are. Specifically, being in a state of constant learning, which I guess ties in with humility, so constantly looking for new stuff, absorbing new knowledge, wanting to learn off other people, the desire to do the best thing you can. It doesn’t necessarily mean be a perfectionist and wanting to make everything perfect before you ship. It’s doing the best you can in the time you have, with the resources you have. That kind of attitude really drives through to great code, great products rather than sloppy work.

    I’ll mis-quote Sartre and say “Hell is other people’s code”

    Write Less Code

    Derrick:
    You’re an advocate for writing less code. Why is this and how can programmers actively work on coding more concisely?

    Pete:
    Yeah, less code. It seems kind of counter-intuitive for a coder but I think most old-hands know what talking about. It’s kind of the case of working smarter not harder. It’s entirely possible to write thousands of lines of code and achieve nothing in it. Think about it, no unnecessary logic, don’t write stuff that doesn’t need to be said, don’t write verbose code. Sometimes you can stretch out boolean expressions into massive if statements which just hide what is being said.

    It’s really a pointless comment, we’ve all seen that haven’t we, code with an essay, and then the function body is really small. Somewhere in the essay there’s some important information but you didn’t need the fifteen paragraphs of comments. No pointless comments, the code just does what it does. The writing of simple but not simplistic code. If you don’t write enough code, it doesn’t do what it’s supposed to do, but just avoiding all those points of needless generality. Don’t make abstracts interfaces, don’t make deep hierarchies that don’t need to be extended, if you don’t need to extend them.

    Communicating Effectively

    Derrick:
    For most professional programmers, development is a social activity in which communication is key, how can programmers begin to communicate more effectively?

    Pete:
    Code is communication. You’re communicating not just to the computer, you are communicating to other people writing the code. Even if you are working by yourself, you are communicating to yourself in two years time when you pick up the same section of code. It’s a skill, and it’s something you learn, and it’s something you consciously practice. I don’t know of courses, Uni courses or practical courses that really focus on something that’s really quite an important skill for programmers. It’s something that you need to consciously practice, you need to consciously work on, you need to be consciously aware of.

    It’s true some people come out the gate better placed than others. Some people can talk well, some people are shy and retiring, but that doesn’t necessarily mean you are stuck like that. That doesn’t necessarily make you a bad communicator. Some people communicate better in different media and it’s worth bearing that in mind. Some guys are really great on email, they can write concise, clear descriptions, they can follow a line of argument writing and explaining something really well. Other people struggle to put it together in words. Learning how you communicate well, playing to your own strengths, then picking the right medium.

    Handling Complexity

    Derrick:
    What are some ways developers can approach managing complexity in software development?

    Pete:
    A key thing to understand is the difference between necessary complexity and unnecessary complexity. The reason people pay us to write software, unless we’re doing it for fun, is because there’s a complicated problem that needs to be solved. There is some level of necessary level of complexity in software engineering and we have to embrace and understand. The problem is the unnecessary complexity. You can take something, a problem you need to solve, add a little bit of complexity, but then if you wrap it up in class design and higher up it reveals itself in architecture.

    One thing I know about well crafted software that basically has the necessary complexity but none of the unnecessary complexity is when I look at it, it looks obvious. That is the key hallmark of some excellent code. You look at it and you just think, “You’ve been working on that for a while” and I look at it and I go, “That’s clearly right.” And you know it wasn’t simple to write. When you look at it the solution’s simple, the shape is simple. All I can say is, that’s what we should strive for.

    I have learned the most in my career when I have been around excellent people

    Derrick:
    What are some things developers can do to tackle messy or bad code bases?

    Pete:
    The most important thing is when you get into your codebase, is to ask people. I see so many developers who just won’t sort of swallow their pride and say, “I don’t quite know what this is doing, but I know Fred over there does. I’ll just go talk to Fred about it.” Often those little bit of insights give you a super fast route through something intractable, a little explanation sort of takes you in there. I’ll mis-quote Sartre and say “Hell is other people’s code.” We all kind of go into that, I do this, and I really struggle with this. I pick up some code, I look at it, that’s a bit dodgy isn’t it. “I really wouldn’t do it like that, what were they thinking, they must be idiots!”

    Then my code, I think it’s great. I understand it perfectly, but then somebody else picks it up, they’ll make that same judgement call on my code. What I think is their terrible hack, is actually some pragmatic thing they did for very good reason. When you’re reading messy code, looking at messy code, enter with humility. Nobody really goes out of their way to write badly. Nobody goes out of their way to write messy code, in general. I can’t say that I’ve found anyone that really tried to ruin a project. Approach code with that attitude.

    The retrospective prime directive, I can’t remember how it goes, we truly believe everyone did the best they could to the best of their abilities at the time given what they knew, etc., etc. This stops you from making judgement calls, stops you from saying oh, I’m going to rip this whole thing out and start again. This teaches you humility to look a little deeper first.

    The standout difference between the really good coders… and the guys that aren’t so great, is attitude

    Keeping Your Skills Up to Date

    Derrick:
    The stuff that we work with is constantly changing and it’s all too easy to find yourself becoming something of a coding dinosaur. What can programmers do to ensure that they keep learning and developing their skills?

    Pete:
    If we value our careers and our skill sets, then this is something you should really be caring about. This is something I find really challenging for myself right now as well. The things I’m focusing on and learning right now are not necessarily coding-related stuff. I’m challenged with learning management, some high-level decision and tactical thinking on a project, rather than dipping into low-level coding stuff. Which is also really fun, but it does mean that I’m pulled away from thinking about the lower-level technical stuff. I want to challenge myself, not get stale and not become that coding dinosaur.

    It’s interesting because I know the tools that I know well, and I do use them regularly, but it is really easy to become stale if I’m not pushing the envelope on my technical skills. The biggest take away I guess though is passion. If you don’t want to become a coding dinosaur you probably won’t, because you care about it enough that you will learn, you will read, you will spend time, you will look at web casts, whatever. If you don’t have the desire to learn. If you don’t have the motivation to do it, that’s when you stagnate. That’s when you become a dinosaur.

    Recommended Resources

    Derrick:
    What are some resources you can recommend for those seeking to become better programmers?

    Pete:
    The biggest thing for me, and that I have done personally and continue to do, is to sit at the feet of great coders. I have learned the most in my career when I have been around excellent people who I can learn off of. Whose skills can rub off on me and I have moved jobs. I have moved myself physically to be able to work with those guys. If you have the liberty to do that, do that. It’s joining in those conversations replying on Twitter, blogging yourself, joining the local user-groups, and all that good stuff.

    You want to become a better programmer? Again it’s the want to be a better programmer, and just stoking that passion. I’m enthusiastic. I love this stuff. If you have an enthusiasm, that passion for programming, it tells out in the code that you write.

    Derrick:
    Really appreciate your passion today. We can definitely see it, and we hope the viewers enjoy it.

    Pete:
    Excellent. Thank you. Cool.

    by Gareth Wilson at June 09, 2015 09:30 AM

    Decyphering Glyph

    Sorry I Unfollowed You

    Since Alex Gaynor wrote his seminal thinkpiece on the subject, “I Hope Twitter Goes Away”, I’ve been wrestling to define my relationship to this often problematic product.

    On the one hand, Twitter has provided me with delightful interactions with human beings who I would not otherwise have had the opportunity to meet or interact with. If you are the sort of person who likes following people, four suggestions I’d make on that front are Melissa 🔔, Gary Bernhardt, Eevee and Matt Blaze, all of whom have blogs but none of whom I would have discovered without Twitter.

    Twitter has also allowed me to reach a larger audience with my writing than I otherwise would have been able to. Lots of people click on links to this blog from Twitter either from following me directly or from a retweet. (Thank you, retweeters, one and all.)

    On the other hand, the effect of using Twitter on my productivity is like having a constant, low-grade headache. While Twitter has never been a particularly bad distraction as measured by hours spent on it (I keep metrics on that, and it’s rarely even in the top 10), I feel like consulting Twitter is something I do when I am stuck, or having to think about something hard. “I’ll just check Twitter” is an easy way to “take a break” right at the moment that I ought to be thinking harder, eliminating distractions, mustering my will to focus.

    This has been particularly stark for me as I’ve been trying to get some real writing done over the last couple of weeks and have been consistently drawing a blank. Given that I have a deadline coming up on Wednesday and another next Monday, something had to give.

    Or, as Joss Whedon put it, when he quit Twitter:

    If I’m going to start writing again, I have to go to the quiet place, and this is the least quiet place I’ve ever been in my life.

    I’m an introvert, and using Twitter is more like being at a gigantic, awkward party all the time than any other online space I’ve ever been in.

    There’s an irony here. Mostly what people like that I put on Twitter (and yes, I’ve checked) are announcements that link to other things, accomplishments in other areas, like a blog post, or a feature in Twisted, but using Twitter itself is inimical to completing those things.

    I’m loath to abandon the positive aspects of Twitter. Some people also use Twitter as a replacement for RSS, and I don’t want to break the way they choose to pay attention to the stuff that I do. And a few of my friends communicate exclusively through direct messages.

    The really “good” thing about Twitter is discovery. It enables you to discover people, content, and, eugh, “brands” that appeal to you. I have discovered things that I enjoy many times. The fundamental problem I am facing, which is a little bit hard to admit to oneself, is that I have discovered enough. I have enough games to play, enough books and articles to read, enough podcasts to listen to, enough movies to watch, enough code to write, enough open source libraries to investigate, that I will be busy for years based on what I already know.

    For me, using Twitter’s timeline at this point to “discover” more things is like being at a delicious buffet, being so full I’m nauseous, and stuffing my pockets with shrimp “just in case” I’m hungry “when I get home” - and then, of course, not going home.

    Even disregarding my desire to produce useful content, if I just want to enjoy consuming content more deeply, I have to take the time to engage with it properly.

    So here’s what I’m doing:

    1. I am turning on the “anyone can direct message me” feature. We’ll see how that goes; I may have to turn it off again later. As always, I’d prefer you send email (or text me, if it’s time-critical).
    2. I am unfollowing literally everyone, and will not follow people in the future. Checking my timeline was the main information junk-food I want to avoid.
    3. Since my timeline, rather than mentions and replies, was my main source of distraction, I’ll continue paying attention to mentions and replies (at least for now; I’ll have to see if that becomes a problem in the absence of a timeline).
    4. In order to avoid producing such information junk-food myself, I’m going to try to directly tweet less, and put more things into brief blog posts so I have enough room to express them. I won’t say “not at all”, but most of the things that I put on Twitter would really be better as longer, more thoughtful articles.

    Please note that there’s nothing prescriptive here. I’m outlining what I’m doing in the hopes that others might recognize similar problems with themselves - if everyone used Twitter this way, there would hardly be a point to the site.

    Also, if I’ve unfollowed you, that doesn’t mean I’m not interested in what you have to say. I already have a way of keeping in touch with people’s more fully-formed ideas: I use Blogtrottr to deliver relevant blog articles to my email. If I previously followed you and you think I might not be reading your blog already (in most cases I believe I already am), please feel free to drop me a line with an RSS link.

    by Glyph at June 09, 2015 12:41 AM

    June 08, 2015

    Giles Bowkett

    June 07, 2015

    Dave Winer

    What changes at Medium and Yahoo Pipes teach us about the persistence of the web

    Yesterday I did a review of the feeds I follow for tech news, and posted a request to Facebook for people to recommend their favorites. In this review I came across a "MegaFeed" for Glenn Fleishman, a blogger who also writes for a number of publishers. The feed is stitched together by Yahoo Pipes, a service that has been around for many years. They announced last week that the site will close in September. There is a discussion on Yahoo's support forum.

    I wondered what will happen to the people who follow feeds produced by Yahoo Pipes? Yahoo doesn't say they'll provide free redirection, but it would be good for the web if they did. However, even if they did provide redirection, where would people redirect to? Because Yahoo was a big company people trusted and their service was free, little if any competition developed for Yahoo Pipes. Either way, it's a clear example of why it's not good to depend on free commercial services to form critical parts of your content infrastructure.

    Then I read stories on BuzzFeed, Business Insider and Fortune about recent changes at Medium, another site where people post their ideas, instead of posting to a blog that they pay for and control.

    When people post to Medium they think about exposure for their ideas today, but imho they should also be thinking about how people are going to find their ideas in the future. There's no guarantee that Medium won't shift strategy again, or shut down. It happens all the time in the tech world. With no way to dual-host content, and no guarantee of future redirection, Medium is not a very future-safe place to post.

    But even sites like Tumblr and WordPress.com that look stable are still subject to corporate changes or disappearance.

    What we need, and still don't have, is a systematic way of publishing to the future. Such a system would allow you to pay a fixed sum to keep your content at a specific address for the foreseeable future. No one can make a guarantee, we don't know what the future holds, but every effort has to be made, upfront, to be sure that the content has the best chance to survive as long as possible.

    It would be nice if a visionary entrepreneur would get involved, and an educational institution, perhaps, and/or an insurance company, the kinds of organizations our society creates to be long-lived. It would be great to get input from Stewart Brand and his colleagues at the LongNow Foundation.

    I've said this many times, it bears saying again. I've been aware of this problem for a long time, and I'm hosting a lot of archives that should be preserved long-term. I want them to be, I'd be willing to bequeath the funds in my will to keep the content going for the indefinite future, but today there is no way to do it, as far as I know.

    PS: People always say archive.org is the answer. Of course I'm aware of that excellent and wonderful service. But long-lived content is not the same thing as having a snapshot. We're building networks here. Archive.org is a museum. I'm very glad it exists. I want something different, a way for the actual content and the networks they're part of, to persist.

    PPS: An after-the-fact open source release of Yahoo Pipes probably isn't an answer.

    June 07, 2015 05:31 PM

    June 04, 2015

    Dave Winer

    Throwback to 2001

    This picture was taken in my office in 2001.

    A picture named dave2000.png

    This is when RSS was just taking off. We were working on Radio 8.

    I like the Windex bottle. I kept it near to clean the monitor and my glasses. I was a smoker then, so I guess things got smokey?

    Gumby was part of the entourage.

    June 04, 2015 05:59 PM

    Blue Sky on Mars

    Utter Disregard for Git Commit History

    Look, I don’t give two shits about my Git commits.

    I have no shame — okay, maybe a little shame — dropping these commits into my repositories:

    Commit list

    Over the last five years, I’ve gotten a lot of questions along the lines of “should I rebase my branches or deal with a merge commit or maybe even squash all of my commits down into a single commit before merging?” Like most pedantic programmer debates, my answer is usually “I don’t care, I’m going to grab another slice of pizza, you do you”, but I’ve been thinking about this a lot recently and I think there’s a more interesting question to consider instead:

    Why do developers take different approaches to repository histories?

    A tale of two changes

    My favorite commit author of all time is Jeff King (@peff). I like his commits so much that even if I were the Sepp Blatter of the Commit Olympic Committee, I wouldn’t need to be bribed to nominate him as a finalist. He’s the number two committer to Git itself, and his commits are truly lovely to read. More often than not, the diff may only be a couple of lines but he'll likely include a detailed, multi-page writeup with code examples and performance benchmarks in the commit message.

    Peff's commit

    This works for git-core because their unit of change is at the commit level. Each commit is designed to be a comprehensive, standalone measurement of the change introduced into the repository. This is a byproduct of their process: contributors are to use git format-patch and git send-email to send their patches to the mailing list so that changes can be efficiently reviewed, discussed, and merged to master.

    Git’s maintainers would say this commit process is designed to ensure speed, quality, and safety. They should know; they’re the best example of working efficiently within Git.

    On the flipside, GitHub is the best example of how to work within github.com, and if you ask them, they’d probably defend their process with the exact same rational: it allows them to move with speed, quality, and safety. Every single change enters production via a pull request, and as such, the pull request is king... not necessarily the commit.

    Nathan Sobo (@nathansobo) is one of my favorite pull request authors. It’s an egregious example for the sake of illustration, but take a look at this particular commit on the Atom repository. It’s a fairly stereotypical commit for GitHubbers: hell, even the commit message itself is emoji. This would not get accepted in git-core.

    Nathan's pull request

    But click up from the commit's page and take a look at the pull request and the general format becomes immediately familiar: it’s an extremely well-written and accessible discussion of the changes in that pull, complete with the analysis of the performance impact it will have. It effectively serves the same purpose as one of Peff’s individual commits.

    Units of change

    These are two extremes of viewing what the core unit of change is for the respective project. From Git’s perspective — likely because of the ease of use inside a mailing list approach — a single atomic commit makes most sense. From GitHub’s perspective, individual commits become less valuable because the atomic unit is the pull request. In both cases, more historical context on a change can be easily found by going back to the mailing list discussion or the pull request conversation.

    I’m a product of GitHub culture, so I tend to throw a lot of commits into my projects. It leads to having more reference points to refer back to in the future. This is particularly true if I’m doing frontend work that requires some experimentation before I know what I’ll ultimately end up with.

    Sometimes I’ll even deliberately push a commit and immediately revert it because I want a record of one possible experiment was. Rebasing out these “mistakes” down to a single commit makes it harder for me to see what I was playing with in the past. All of this leads to a dirty commit history, but I use pull requests to see that history.

    That said, I'm extremely apathetic to this debate. Whatever makes the most sense for your team, go ahead and do it. Certainly successful projects can and have been built on either approach, or a hybrid of the two.

    Limitations

    Sometimes I wish version control had a bit better control over this. It might be interesting if Git had a new object that was below the Commit object — maybe a ExperimentalCommit that would get folded into a single Commit once it went through code review. That way, each developer could commit their scratchpad experimentations to mainline (so they can refer back to them in the future), but a separate commit history of code review could be generated and used as the “clean” history.

    That said, I don’t actually want the added cognitive overhead of expanding Git’s simple object model, either, so I'm not seriously proposing this. It's fun to envision a system where the two mindsets could live together a bit more harmoniously.

    Food for thought for the next hot version control system, perhaps.


    Anyway, what I’m trying to say is that git commit -m “unfuck this” shouldn’t necessarily be a capital crime. I think it’s a little more interesting than that. Look at the unit of change… that’s where the real work happens.

    June 04, 2015 12:00 AM

    June 03, 2015

    Fog Creek

    Conquering Large Legacy Software – Interview with Mike Long

    .little {font-size: 75%}
    Conquering Large Legacy Software – Interview with Mike Long

    Looking for audio only? Listen on

    We interviewed Mike Long, partner at Praqma, and author of ‘Conquering Large Legacy Software’, a field manual for dealing with large, long-lived projects. We discuss how to deal with large legacy codebases, in particular, how to get started, where to focus your attention to maximize returns and how to approach adding tests.

    Content and Timings

    • Introduction (0:00)
    • About Mike (0:26)
    • Getting Started with Large, Legacy Codebases (1:38)
    • Realistic Goals of Improving Legacy Software (3:30)
    • Where to Focus your Efforts (4:04)
    • To Re-write or Improve? (5:12)
    • Tools to Understand Legacy Codebases (6:38)
    • Adding Tests to Legacy Code (7:22)

    Transcript

    Introduction

    Derrick:
    Mike Long is a software consultant and partner at Praqma. He’s a regular conference speaker focusing on areas like cleaning code, long-life software, and continuous delivery. He’s the author of ‘Conquering Large Legacy Software’, a field manual for dealing with large long-lived projects. Mike, thank you so much for taking time to join us today. Why don’t you share a bit about yourself?

    About Mike

    Mike:
    I was born in Australia. I grew up in Scotland, and after University I started my career in England working on drilling tools. After that I moved to Oslo and was there for 5 years working on a giant marine seismic acquisition system. Then I spent the last 3 years in China working on a large legacy system. Since I came back to Norway last summer I’ve been focusing on continuous delivery. I’ve been helping teams adopt modern technical practices in usually complex development problems.

    Derrick:
    Problems in dealing with legacy software are well known. Out-of-date technologies, code no-one understands and no tests, yet few organizations seem to actively work to prevent such issues from occurring. Why do you think is?

    Mike:
    It’s easy to try and point to one of the biggest core reasons that I see that is that there’s a big imbalance and power between the business side of the organizations and the technical side of organizations. When that occurs, when you don’t have strong spokespeople for the software, then you tend to get decisions that are not at the best interest of the software and business in the long term.

    I think the biggest mistake people make is that they don’t start

    Getting Started with Large, Legacy Codebases

    Derrick:
    Just getting started with improving legacy software can be difficult, so where do you recommend people start?

    Mike:
    I guess the challenge for most people that are dealing large legacy systems is that the problem can be so overwhelming that they find it hard to pick a target. What I recommend is to focus on what you’re changing. There’s no sense in spending efforts to improve code or improve the software development process of a part of a system that isn’t changing. If it’s not changing, then you don’t have bugs there because you’re not fixing them, you’re not adding new features there, so the return on improving those areas of the code base is usually very low. If you focus on where people are actively investing their time, you’ll get much better returns on those investments.

    The second thing is when you talk about large legacy systems, I think that the big problem is not the legacy side of things it’s the large side of things. Large monolithic systems are usually a pain point. It’s not the fact that the software isn’t as good as it could be, it’s the software is so big that actually working with it becomes a very slow process. All the tools are very large. Even checking out the changes is a very big process. Doing a build can take a long time. All these frictions in the development process are a big pain. If you can focus on breaking this monolith up into smaller parts that can each have their own release schedule, their own development pipeline, their own tooling, then you will get a much improved development efficiency there.

    That brings me to the third point which is to automate the donkey work. All the stuff that happens manually that could be automated is a great investment. People are the most expensive line item in most software organizations, so if you can find ways to free them up to do value adding work rather than donkey work you’ll get returns very quickly.

    Realistic Goals of Improving Legacy Software

    Derrick:
    What are some realistic goals of improving legacy software?

    Mike:
    Realistically, that’s a challenge because it really depends on what you’re prepared to invest. That in turn is dependent on what your future of the software is. Say you have 20 million lines of code and you’re not very happy with them. The realistic goals are not to improve 20 million lines of code. That’s not going to fly. The realistic improvements are to automate the donkey work, to break up the monolith, to focus on the areas that people are already investing their time on because then you get the return on the investment.

    Where to Focus your Efforts

    Derrick:
    How can you go about measuring the quality of a large legacy system to see where the efforts should be directed?

    Mike:
    I think as software people, we have lots of tools. Tools aren’t the problem with software actually. We have very good tools for the way we work. To get feedback on your code is quite simple. If you want to find out what your code coverage is, what your complexity is, all these things are very easy to figure out and there’s great tool support in terms of static and dynamic analysis and this kind of thing.

    I think one of the most common feedback mechanisms that people mess up on, not just legacy software but software in general, is to tag their change sets when they’re fixing bugs. If you actually tied every time you’re making a change to software in response to a bug, over time you can find out, not only your defect rate, but where in your software those defects occur. You can map them out in your codebase. That’s a very powerful thing. That’s a great way to figure out where to focus your efforts on. That directly feeds back into a return on investment because if you can do preventative work on a place that is error prone that will pay back very quickly.

    To Re-write or Improve?

    Derrick:
    What factors should you consider when deciding whether to rewrite or improve the current
    system?

    Mike:
    If you were to ask Joe Spolsky, he would say never rewrite. I think that, in general, that’s a good rule of thumb. If you have to pick a rule of thumb that’s not a bad one because any significantly valuable piece of software has had a huge investment on it. To assume that you can rewrite it in a way that’s going to provide return on investment is usually very naïve. In my experience, there’s only a couple of cases when it’s a good idea to rewrite. One is that if nobody cares, if there’s no financial cost associated, and of course, open source is a great example, where we make gitlib2 to. It doesn’t matter that there’s already a get library out there. We can make another one because we don’t have the financial constraints.

    The other example is if, like some of these very old systems, there’s no source code around anymore or the tools aren’t, or the mainframes are being decommissioned, or there’s a platform obsolescence, and there are oftentimes when you have to say, “Well, okay, we’re just have to suck it up and rewrite it because we really don’t have any way to carry this forward.” One of the interesting things about modern times is that architectures are much more stable. x86 has been around for a long time, and code that was written in the 90s is still easy to run on modern systems for better or worse. There’s a great deal of effort going into backward compatibility. Those problems of platform obsolescence issues are becoming less and less of a reason for rewriting.

    Tools to Understand Legacy Codebases

    Derrick:
    Are there any tools that one can use to help gain an understanding of that current go base and steps to improve it?

    Mike:
    Yes, there are. In my experience they have different payoffs and they’re very context dependent. If you are dealing with a very large codebase that has unmanaged memory management, you have to do manual memory management. You can get a lot of value out of using a static and dynamic analysis tools to track whether you’re doing the right things with memory, whether you’re going beyond buffer bounds, whether you’re trashing your stack when you don’t even know. There’s great tools out there for that and you should definitely give them a try. Again, it’s very context dependent so don’t rush out and buy tools. Evaluate them and see whether they provide value in your context first.

    You don’t have to look very far in a legacy project to get some wins

    Adding Tests to Legacy Code

    Derrick:
    The common problem with legacy software is the lack of tests. How should you approach testing legacy software?

    Mike:
    Try and get a safety net around the stuff that you’re changing. Typically, the common body of knowledge says, “Unit tests are the way to go.” In a lot of ways that’s very true. As you write code writing unit tests is a very low-cost, low-friction way to get high-quality software. In legacy systems it’s usually very, very difficult to get unit tests into it and breaking those dependencies is very hard. On the other hand you have an awful lot of existing functionality at the user level that you have to keep in a vice. You don’t want to break it. Normally large legacy software tends to have much more end-to-end full system maybe user-interface driven tests which are slow. They’re painful. Getting those things up and running are actually not as expensive as you would imagine, and they can provide a lot of value if you have enough people hammering on a codebase just to give you that safety net, then as you are changing code work on the unit tests and lower level testing.

    Derrick:
    What are some typical opportunities to reduce waste in legacy projects?

    Mike:
    Oh, there’s waste everywhere. You don’t have to look very far in a legacy project to get some wins. As software people, we tend to make the same mistake over and over again and that we wildly overestimate the time it would take to do refactoring and improvement. We wildly underestimate the time it takes to implement features. When we have to make those short-term trade-offs, we always take the wrong choice. On the other hand, once you’ve come to realization that something needs to be done, you don’t have to look far to find quick win. Usually around automation, big systems usually have suffered from poor automation, you can often through a hardware problem as well, as simple thing like just getting some really beefy build service to cut the developer feedback clips is a great way to get the quick win.

    Something often overlooked when people are looking at a software problem, if you go in and spend some money on service, you can save millions of dollars on engineering time. You have to think like that. You have to go for the big wins that you can get and then slowly will chip away at the longer term payoffs.

    Focus on breaking this monolith up

    Derrick:
    Are there any common mistakes people make when trying to tackle legacy software?

    Mike:
    I think the biggest mistake people make is that they don’t start. It’s not that they’ve gone in the wrong direction or they’ve improved the wrong thing. In general, if you have some focus on continuous improvement, you’ll get some wins. The biggest mistake I see in large legacy projects is that people just don’t start. They don’t understand that there’s a really valuable payoff in spending the time to work on this stuff and just rolling up their sleeves and getting on with it.

    Derrick:
    What are some resources you can recommend for those working with legacy software?

    Mike:
    I would be remiss if I didn’t mention Michael Feathers’ book. It is actually a very good book, and if you want to learn how to get legacy software under test, it’s a great resource. It’s got lots of good techniques. If you’re working as part of a team, form a study group or end it. Just learn it.

    Derrick:
    Thank you so much for taking time to join us today.

    Mike:
    Thanks a lot. No problem.

    by Gareth Wilson at June 03, 2015 09:20 AM

    Dave Winer

    The rssCloud docs...

    I did a bad thing, I let the domain rsscloud.org lapse.

    When I did that, all the rssCloud docs fell off the web. ;-(

    We need them back, so I bought rsscloud.co. It isn't perfect but most of the docs now work.

    The main pages

    home.rsscloud.co

    publisher.rsscloud.co

    walkthrough.rsscloud.co

    cribsheet.rsscloud.co

    tool.rsscloud.co

    rssCloud in JavaScript

    Also, Andrew Shell released the first version of his rssCloud-server implementation for Node.js.

    This is a big milestone. Thank you Andrew.

    June 03, 2015 12:14 AM

    June 02, 2015

    Mark Bernstein

    Tinderbox 6.3

    Tinderbox 6.3

    Tinderbox 6.3 is now available. Highlights include ❧ gorgeous and informative treemaps ❧ a fresh walkthrough about agents, actions, and dashboards – some of Tinderbox’s most asked-about features ❧ big speed bump in large and complex maps ❧ dozens of small fixes and extensions. See the upgrade page for all the details.

    The built-in walkthrough for agents and dashboards covers should be especially helpful for new Tinderbox users. Here’s one tab from the example:

    Tinderbox 6.3

    That’s keeping track of expenses during an impromptu business trip. We’ve got running totals, expense distribution, category totals – even a dashboard to remind us to write up the boring daily summaries for which Accounting always pesters us.

    As usual, updates are free if you’ve purchased Tinderbox or a Tinderbox upgrade in the past year. You can upgrade from any version of Tinderbox for $98, or subscribe to automatic renewals for just $83.

    Tinderbox 6.3

    Another tab of the example: an agent plucks out each major city in our heroine’s epic business trip.

    June 02, 2015 03:21 PM

    Dave Winer

    Connecting Slack with RSS

    I set up a test channel on Slack and hooked it up to the Hacker News "firehose" feed, which is fairly high volume. About 20 or 30 posts per hour. I wanted to see how fast it would update.

    I also wrote a small Node.js app that reads the same feed and posts to another Slack channel, as a control. It will post at most one item per minute. So they come out fairly steadily as long as more items are being posted to Hacker News.

    I have also set up an IFTTT recipe to read the feed and see how it compares.

    Update #1

    It took about 1/2 hour for IFTTT to push a dozen items to our group at once.

    Update #2

    Another 1/4 hour another storm of updates from IFTTT.

    Still nothing from Slack's RSS bot.

    My Node app is chugging along, posting one item a minute.

    Update #3 -- 12:20PM Eastern

    It's been over an hour and still nothing from Slack.

    Update #4 -- 2:40PM Eastern

    We are now getting updates from Slack's native RSS support.

    They do more than report headlines, they're scraping the articles that are being linked to from the HN firehose feed.

    But they're doing that with some of the links we push from the Node.js app.

    And now it's been a couple of hours since the IFTTT bot has posted any new stuff, yet the feed is updating continually.

    Then as if by magic a small flood of IFTTT posts from the feed.

    Early conclusions: Slack's native integration is slow and bursty. IFTTT is more regular but bursty. Lots of messages all at once. Neither is ideal for a frequently updating feed.

    June 02, 2015 02:42 PM

    June 01, 2015

    Dave Winer

    How I try to work with journalists

    I read this piece by Charles Arthur thinking maybe this is the breakthrough. Maybe we can start this discussion in earnest. Maybe in fact a lot was gained by putting programmers and journalists in the same room, if only to prove that's not the way to do it!

    Here's how I think it should work, and I think the germ of the idea is there in Charles' piece. He says he is an amateur programmer. He can do some PHP and AppleScript. In the past he's worked a bit in COBOL and C++. That's awesome. We can use that.

    How about if we make great tools that are designed for people like Charles to create their own wonderful web projects.

    Two good things could come from it.

    1. They might make some good software. Don't doubt it. One of my best programmer buddies was a lawyer. He had a good programmer mind, but hadn't really exercised it. Now he teaches me stuff about Node.js. By giving ever-easier and less complex development tools to people who aren't developers, we're going to as a result find some of them are better devs than they are journalists. I believe those people will be uniquely able to listen to journalists, because inside their own mind there is one.

    2. They might create a breakthrough. It might also be an egregious hack, that you can't believe a human mind could possibly do it so wrong, but it might still be a great idea! That's exactly how Adam Curry showed me how to do the "last yard" idea he wanted to do that resulted in podcasting. He took my source code, and hacked it in awful egregious ways (I can't say that enough) but it did something I had not thought of. He had tried to explain it in words, but couldn't get through my thick skull. But showing me that he believed in the idea enough to so thoroughly humiliate himself was enough to get me to listen.

    There probably are other great reasons, but these are two that I have personally experienced, so can vouch for the fact that they're real.

    So believing this, for a very long time actually, I have been working at trying to lower the barriers. I called one of my companies UserLand, because I wanted the users more involved in creating software.

    I have shipped a bunch of tools that make it easy for an inspired user to cobble together their own web server, their own CMS, without the limits of the software that was created by a priesthood, one that's invested in keeping things complicated and inaccessible. (I'm sure journalists are familiar with the idea of an elite priesthood.)

    That's why I say to Charles, to think of all programmers as having the same outlook, the same goals, is as ridiculous as thinking all columnists and reporters do. I want you to win. Most of the others don't really care if you do or don't.

    I keep saying this, let's work together. Maybe now we can?

    June 01, 2015 06:25 PM

    Mark Bernstein

    How Not To Crash #7

    How Not To Crash #7 sounds like a nifty cocktail -- perhaps something you’d enjoy after finishing your Corpse Reviver #2. But it’s the latest installment of Brent Simmons important series of notes on avoiding crashes in contemporary software.

    This one concerns “Dealing With Nothing” or, more precisely, coping with situations where the object you’re processing is nothing at all. For example, you might have methods that display selected objects; what happens when nothing is selected? Or you might be displaying a shopping cart at checkout: what happens when the shopping cart is empty?

    One technique Brent doesn’t mention is the null object pattern. In his example, we might call

    [self doStuff:thing];

    If doStuff: expects thing to be an object and you give it nil, you might well crash and that’s a very bad thing to do and deplored by all right-thinking folk. Brent suggests that doStuff: should both assert that thing isn’t nil and guard against nil things, e.g.

    NSParameterAssert(thing);

    if (thing) {menuItem.title=thing;}

    This is often a good idea. The first time I saw it, in John Daub’s PowerPlant, it seemed exorbitant: who could remember to include all those guards in every method? Soon, though, it becomes a reflex and you write (and read) the guards without needing to think about them.

    If you do find yourself writing lots of if(thing)... tests, though, you might be better off passing a Null Object -- a subclass of the expected class that does nothing, and does it quickly.

    For example, Tinderbox has a class for LayoutPolicy -- objects that know how to lay out maps, or outlines, or treemaps. In the old days, before using the LayoutPolicy, we’d carefully check that the layout policy actually existed. This solves problems when you're building a new window, or closing an old one, or changing the view right in the middle of a screen update, but it does lead to an awful lot of code that simply makes sure the layout policy is where it ought to be.

    So, instead of checking, Tinderbox initializes views with an instance of NoLayoutPolicy. If a view is being constructed and isn't quite ready to do real work, we can still call layoutPolicy->Prepare() in perfect safety. If we’re about to disassemble a window, we can replace its layout policy with a fresh NoLayoutPolicy, confident that if someone tries to refresh the window we’re demolishing, there will be a NoLayoutPolicy standing ready to do nothing. Because there’s always a layout policy -- even if it’s only a NoLayoutPolicy -- we can take all those null check and dump them all in the trash.

    We’ve got NoLayoutPolicy, NoDrawingPolicy, NotAnAttribute, NotANode. We’ve got plenty of nothing.

    June 01, 2015 03:03 PM

    Deadline

    Mira Grant continues her newshounds vs. zombie romp, picking up where Feed left off. Unfortunately, Feed left off with the death of its best character, teenage newsie Georgia Mason, and leaves us in first person with her haunted, daredevil brother Shaun. Not only is Shaun less attractive than his sister, but he is by design less involved, a slacker-daredevil who doesn’t care deeply about anything. Georgia was obsessed with getting the news out, and that gives us a lever for moving the world; Shaun is obsessed with the memory of his dead sister, and that’s a more slender reed.

    But it’s enough: there’s something here, though we really have no idea at this point exactly what it is. Our gang of teenage newshounds is now running one of the world’s top news sites, an organization nearing open war with the CDC, that ruthless and powerful zombie-control agency. Our kids our rich and they’re restless and even if it might be the end of the world, they’ve got each other – in a sense, anyway.

    June 01, 2015 01:52 PM

    John Udell

    Working observably: The next best thing to being there

    When I joined Hypothesis, my new employer, I wondered: "Why are we using IRC instead of Slack?"

    It boiled down to three reasons. First: inertia. The company had established an IRC culture before Slack existed. Second: openness. We're an open source nonprofit, so we operate in public mode as much as we can, and Slack doesn't yet support that mode natively. Third: skepticism. Sure, Slack is the flavor of the month, and all the cool kids use it, but is that really the right reason to switch from standard IRC to a slightly-improved-but-proprietary implementation of IRC?

    [ Get the most out of collaborative programming with InfoWorld's 20 essential pointers for Git and GitHub. | Keep up with hot topics in programming with InfoWorld's Application Development newsletter. ]

    We continue to waffle on the subject. I expect we'll land in the Slack camp eventually because, to be honest, we do want to play with the cool kids on their home turf. Meanwhile, though, we're enjoying the same kind of virtual water-cooler effect in IRC that we'd be enjoying in Slack.

    To read this article in full or to leave a comment, please click here

    by Jon Udell at June 01, 2015 10:00 AM

    May 31, 2015

    Tim Ferriss

    TF-StitcherButton

    sacca_discoGoofing around with Sacca and his afro.

    “Fuck it… I’m just not going to play this traditionally anymore.”
    – Chris Sacca

    Chris Sacca was recently the cover story of the “Midas Issue” of Forbes Magazine.

    The reason: He is a newly-minted billionaire and the proprietor of what will likely be the most successful venture capital fund in history: LOWERCASE I of LOWERCASE Capital.

    He’s an early-stage investor in companies like Twitter, Uber, Instagram, Kickstarter, and many more.

    In this interview, we discuss unfair advantages, how Chris chooses founders and investments, stories of missed opportunities, the styles that differentiate Wall Street from Silicon Valley investors, and how keg parties can liberate law students from the tyranny of class (Chris completed law school without attending any classes).

    Enjoy!

    TF-ItunesButtonTF-StitcherButton

    This episode mentions the incredible Matt Mullenweg. Matt, who’s also been on this podcast, was a lead developer behind WordPress, which runs about 23% of the Internet. You can listen to our booze-infused conversation here, in which we discuss polyphasic sleep, tequila, and building billion-dollar companies like his current gig (stream below or right-click here to download):


    This podcast is brought to you by MeUndiesHave you ever wanted to be as powerful as a mullet-wearing ninja from the 1980’s, or as sleek as a black panther in the Amazon? Of course you have, and that’s where MeUndies comes in. I’ve spent the last 2-3 weeks wearing underwear from these guys 24/7, and they are the most comfortable and colorful underwear I’ve ever owned. Their materials are 2x softer than cotton, as evaluated using the Kawabata method. Check out MeUndies.com/Tim to see my current faves (some are awesomely ridiculous) and, while you’re at it, don’t miss lots of hot ladies wearing MeUndies.

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Give it a test run..

    QUESTION(S) OF THE DAY: What’s the best investment advice you ever received? Or worst? Please let me know in the comments.

    Scroll below for links and show notes…

    Selected Links from the Episode

    Show Notes

    • What is Chris Sacca best known for? [6:10]
    • Total Immersion swimming and how to invest like Chris Sacca [8:40]
    • Pieces of advice given to Chris Sacca on early-stage investing [11:55]
    • What disqualifies startup founders in Sacca’s mind [16:05]
    • Travis Kalanick and Nintendo Wii Tennis [18:55]
    • Traits of founders for whom success, at massive scale, is predestined [22:00]
    • The whales that got away: GoPro, Snapchat, and more [27:40]
    • On letting the negative case dominate one’s analysis for whether to invest or not [29:55]
    • Differences between venture capitalists and private equity [35:15]
    • Books for investing and cultivating emotional intelligence [41:00]
    • Thoughts on modeling what it is to be successful [49:30]
    • What Chris Sacca’s parents did when he was a kid [53:50]
    • What Sacca looks for when hiring [58:25]
    • What historical figure Sacca most identifies with? [1:01:15]
    • Early collecting habits [1:04:25]
    • The story of the prophetic notebook [1:10:10]
    • The two differentiators that shifted the nature of Sacca’s business [1:19:10]
    • Advice to founders or would-be entrepreneurs [1:27:40]
    • Most readily quoted movie [1:31:10]

    People Mentioned

    by Ian Robinson at May 31, 2015 12:29 AM

    May 30, 2015

    Mark Bernstein

    A Natural History of Dragons: A Memoir by Lady Trent

    A young lady of the rural gentry develops a certain passion for natural history, both of her native Scirland and most especially of dragons and their kin, creatures of remote lands. In time, she marries a tolerant young man of considerable means who shares a certain amateur interest in natural philosophy, and they join an expedition to a remote Balkan-like land where dragons may be found amidst colorful (if superstitious) villagers.

    I’m not entirely sure that this story is best told in fantasy or whether, if we do want a fantasy, whether the setting chosen here – the technology seems to be last 18th century while manners are mid-19th and fashions later still – is ideal. Despite the dragons (and some nice archeological interludes) the world is not very strange.

    May 30, 2015 02:10 PM

    May 29, 2015

    Mark Bernstein

    The Whites

    Cited by Joyce Carol Oates as carrying much of its narrative on the back of interrogation, this is a book with a ton of energy and buckets of interrogation. Police officers interrogate each other, interrogate their subordinates, interrogate their wives, and also interrogate suspects. An impressive feature here is the rich array of transient incident that drifts through the lives of police officers; ever night brings three or four fresh runs, each with its own random miseries.

    May 29, 2015 10:29 PM

    Dave Winer

    My website in a Dropbox

    I wanted to mark a milestone. I finally have a web server running out of a Dropbox folder. I tried doing this with Apache a few years ago, but there was something about how Apache worked that drove Dropbox crazy. Or vice versa.

    Now I have my own web server, written in JavaScript, built out of Node.js core packages. It's really fast and reliable, and I pretty much know exactly what it's doing. There was never a problem with Dropbox. We just read the files from the server. We update our own stats files, but that doesn't seem to be too much for Dropbox to handle. (It is using up a lot of CPU cycles on the server, according to the Top command, so I'm thinking about turning Dropbox off when I'm not actively developing.)

    Why it's so cool -- all my tools work with the filesystem. It's even more widely supported than Git. And there's no difference between the original content and the stuff that's being served. If I want to edit one of the files in my website, I just open it in an editor, make the changes and save. It's like having the server on my machine, without actually having the server on my machine.

    The server is called PagePark. Of all my latest tools, it's my favorite. I love tweaking it, adding little shortcuts. Things that make it work really well for the kind of content I serve.

    May 29, 2015 12:49 PM

    Tim Ferriss

    TF-StitcherButton

    TF_cowboySometimes, going weird allows you to go big. (Photo: My weird Instagram)

    In this episode, I answer questions submitted by you all.

    50% of this episode is spent explaining how I’d build an audience from scratch, if I had to start over today. The other ~10 questions/topics are listed below.

    Do you like or dislike this type of episode? Please let me know in the comments, and I’ll do more or fewer based on that.

    For the movie recommendations I mention (shorts, documentaries, etc.), click here to see the growing list.

    Enjoy!

    TF-ItunesButtonTF-StitcherButton

    TF-ItunesButtonTF-StitcherButton

    If you enjoy the above Q&A episode, you might also like this episode, where I answer the question: “What would you add to The 4-Hour Workweek for 2015?”

    Other questions I answer in this episode:

    If you’re the average of the 5 people you surround yourself with, who are those 5 people for you?

    Based on the self-experiments you conducted in your books, are there any habits you continue to implement on a daily basis?

    What is the most important question you ask yourself everyday?

    If you could make one new thing mandatory in the nationwide high school curriculum, what would it be?

    Bruce Lee said “The successful warrior is the average man, with laser-like focus.” What methods do you practice to maintain focus and follow through to achieve your goals rather than getting side tracked, distracted, or discouraged?

    With all the misleading information on health out there, what are the best/most reliable resources?

    What are your top 10 natural supplements that you’ve found most helpful?

    What are the things you’ve done to become a better writer?

    What are your guilty pleasures for those times when your brain needs a rest?

    What would you go back and tell your younger self?

    Again, here are my answers.

    ###

    For previous episodes of the podcast, including Arnold Schwarzenegger, Rick Rubin, Jon Favreau, and others, click here.

    by Tim Ferriss at May 29, 2015 12:53 AM

    May 28, 2015

    Lambda the Ultimate

    Second-order logic explained in plain English

    John Corcoran, Second-order logic explained in plain English, in Logic, Meaning and Computation: Essays in Memory of Alonzo Church, ed. Anderson and Zelëny.

    There is something a little bit Guy Steele-ish about trying to explain the fundamentals of second-order logic (SOL, the logic that Quine branded as set theory in sheep's clothing) and its model theory while avoiding any formalisation. This paper introduces the ideas of SOL via looking at logics with finite, countable and uncountable models, and then talks about FOL and SOL as being complementary approaches to axiomatisation that are each deficient by themself. He ends with a plea for SOL as being an essential tool at least as a heuristic.

    May 28, 2015 08:18 PM

    Fog Creek

    dev.life – Interview with Casey Muratori

    In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

    Today’s guest is Casey Muratori, Software Engineer at Molly Rocket. He’s the creator of Handmade Hero, an ongoing project to create a complete, professional-quality game without the use of engines or libraries, that’s accompanied by videos explaining every line of source code via weekday live coding sessions.


    Casey Muratori
    Location: Seattle, WA, US
    Current Role: Software Engineer at Molly Rocket

    How did you get into software development?

    I learned to program when I was 7 years old. My father worked for Digital Equipment Corporation at the time and he was a programmer by trade, so he taught me when he thought I was old enough to handle it. I had always been fascinated with computers, and even when I was much too young to program, I had pestered my father to let me use the VT terminals and the DEC Rainbow that he’d bring home from work. I’m not sure why I was so interested in things as mundane as a VT terminal, but I was.

    From 7 years old to today, over 30 years later, I’ve been programming computers in one capacity or another. I never went to college for it, I started working straight out of high school. My first job was in the games industry, and I never really switched industries, although for most of the time I did game technology exclusively (as opposed to working directly on specific games) at RAD Game Tools.

    vt (1)

    Tell us a little about your current role

    During the day, I handle the art direction and management responsibilities for Molly Rocket, and I do all the programming. We have two projects we’re working on right now but neither have been announced, so I can’t say much about those at the moment, although I hope to have at least one of them announced publicly sometime before the end of the year. At about 4:30 I go home from the Molly office, and I start streaming Handmade Hero on Twitch. This takes about two hours or so, where one hour is me teaching programming, and the other hour is me answering questions or chatting with the folks who watch.

    I’m currently working on interactive fiction technology. Obviously, it is an extremely challenging research area because, to a first order approximation, nobody has shipped any substantive advances in the field since about 1988. So really it’s been stagnant for a good quarter century, which is kind of amazing when you think about how much everything else has progressed in that time. But it’s also a problem that I’ve been thinking about for a very long time, and I feel like there are a number of ways that we can push things forward significantly, so our current goal at Molly is to see if we can make that happen over the next few years. It’s too early to say whether we will succeed, but I’m optimistic.

    When are you at your happiest whilst coding?

    I’m happiest when I’m coding something where I know I have enough time to do the complete right thing. Unfortunately, that’s rarely the case, but I’ve been realizing how important it is to me to make this happen, so lately I’ve been making more plans to try to eventually get to a place where most of my coding can be this kind of coding. It requires improving a lot of the tools (editor, compiler, operating system) so it’s a major investment, but, well, at some point you just have to prioritize what is important to you rather than what is most sensible. I think Jonathan Blow came to this realization recently as well, and that’s why you see him doing all this work on a new programming language now. At some point, you realize that if you want to be able to program the way you want to program, you just can’t do that with tools made by people who don’t understand how you want to program. So you have to start making those tools yourself. It’s too bad, because it’d be great if you could just get tools off the shelf made by people who understand, but I think those days died sometime around when Borland stopped being a compiler powerhouse.

    borlandCompiler (1)

    What is your dev environment?

    I use GNU Emacs for editing code on both Windows and Linux. On Windows, I use Visual Studio 2012 because that’s the last version I happened to buy. On Linux, I use LLVM and GDB.

    There are no software tools that I use that I couldn’t live without – all the tools I use on a daily basis are utter garbage. GNU Emacs is awful – it’s so slow it can barely even auto-indent my files, which is insane considering the horsepower it has to work with. Visual Studio 2012 is pathetic. It takes a perceptible amount of time to step a single line of code in the debugger. That is inexcusable, especially since in the old days (circa MSVC 5), it stepped instantaneously on much less powerful hardware! Their compiler is also, unnecessarily slow in a number of corner cases that I frequently tend to hit.

    Linux is a disaster zone. GDB is the only debugger that seems to actually be functional, and it’s ability to keep you heads-up is awful since it’s not graphical. I’ve tried to use other debuggers, but they’re all basically front-ends for GDB, and most of them do it wrong so that they can’t even properly inspect half the stuff that GDB can. It’s insanity. And forget trying to work with complex graphics setups… debugging code on an Optimus laptop (which is what I have) is an exercise in pure frustration. Every other minor distro update totally breaks debugging under the discrete GPU for one reason or another, which makes debugging complex GPU work a non-starter since the integrated graphics part can’t keep up. Honestly, I find that the dev situation under Linux for native code is so byzantine that it is usually much faster to simply not use a debugger on Linux than to use one.

    And yes, I’m sure everyone out there is like “well just switch to using [their favorite thing]”. No. I’ve tried that thing, because someone else said that exact same thing, and I found that it’s just as awful but in some different way. There are no good dev tools out there today. That much is abundantly clear, and it is a topic on which I find almost all my systems-level programming friends agree, so I think it’s becoming a consensus among people who actually care about low-level code. Nobody is making dev tools for us anymore, and it shows.

    As for my office set up, I use a height-adjustable table. I usually code sitting, but I have a bad right knee so sometimes it helps to switch to standing every so often. I always listen to music when I program, usually on headphones so I don’t bother anyone else.

    What are your favorite books about development?

    I can’t say that I have any, really. It’s been a long time since I’ve read a book about programming. I will say that I quite enjoyed seeing the YouTube video of Mike Acton getting up at cppcon and giving a keynote that was all about how bad C++ is. That was great! And I totally agreed with basically everything he said.

    xeonPhi (1)

    What technologies are you currently trying out?

    Honestly I was really excited for AVX512, because I learned to program the LRB (now Xeon Phi) instruction set a bit when I was working on the drivers at RAD, and I think it’s really cool, but until AVX512 most of those instructions aren’t in the main CPU. Unfortunately, news sites have been reporting recently that AVX512 actually won’t be coming to the desktop this year, I guess, it will be Xeon-only, and that is super depressing. I guess Intel hasn’t said one way or the other, though, so I sure hope they do ship AVX512 on desktop chips sooner rather than later because I think it’s going to be awesome.

    When not coding, what do you like to do?

    Play video games, go to the theater, walk about town. Anything that does not involve me having to interact with nature is usually good. I like to cook, but I’m not particularly good at it.

    What advice would you give to a younger version of yourself starting out in development?

    Don’t ever bother learning or using object-oriented programming. It’s a deeply flawed programming methodology, and I wasted a good five years of my programming life thinking that it was useful, and I’ll never get that back. If I had been able to tell 18-year-old me to stick with compression-oriented programming, I probably would be a much better programmer today and I would have made decent code in my 18 to 23-years old period instead of the garbage OOP code that I ended up making. I will be forever thankful to Jeff Roberts at RAD Game Tools for providing the environment that finally made me realize that OOP was a severe impediment to writing good code, and it didn’t take long in that environment before I was back to writing good code again.

     

    Thanks to Casey for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

    Recent dev.life Interviews

    Eric Lippert
    Eric Lippert
    Chris
    Chris Hartjes
    Paul Jones
    Paul M. Jones
    Michael Fogus
    Michael Fogus

    by Gareth Wilson at May 28, 2015 11:54 AM

    Lambda the Ultimate

    The evolution of Rust

    Graydon Hoare is the original developer of Rust even before Mozilla adopted it. For the 1.0 release he prepared a lightning talk on how the language changed over 10 years.
    He only published some bullet points, but the topic list is interesting as well.

    • Six ways Rust is fundamentally different from how it started
    • Six ways Rust is fundamentally the same as how it started
    • Six things we lost along the way
    • Six things we gained along the way
    • Six things I'm irrationally, disproportionately pleased by

    Read the full blog post for the content of the five lists.

    May 28, 2015 09:12 AM

    May 27, 2015

    Fog Creek

    The Abuse and Misuse of Test Automation – Interview with Alan Page

    .little {font-size: 75%}
    The Abuse and Misuse of Test Automation – Interview with Alan Page

    Looking for audio only? Listen on

    We’ve interviewed Alan Page, author of ‘The “A” Word: Under the Covers of Test Automation’. We discuss the abuse and misuse of test automation, when to automate a test, the problems of GUI test automation as well as good test design factors. Hear more about testing from Alan over on his blog and the AB Testing podcast.

    Content and Timings

    • Introduction (0:00)
    • About Alan (0:28)
    • The Overuse and Abuse of Test Automation (0:53)
    • When to Automate a Test (4:06)
    • Problems with GUI Testing Automation (6:50)
    • Good Test Design Factors (9:50)
    • What Kinds of Tests Are Suited to Automation (12:37)
    • Recommended Resources (14:12)

    Transcript

    Introduction

    Derrick:
    Alan Page has more than 20 years of software and software testing experience, primarily at Microsoft. Fittingly, he was lead author of the book “How We Test Software at Microsoft.” He has recently published “The A Word: Under the Covers of Test Automation”, a collection of blog posts about the appropriate application of automation in testing. Alan, thank you so much for taking the time to join us today. Do you have a bit to share about yourself?

    About Alan

    Alan:
    I’m really excited to be here. I’ve been a big fan of Fog Creek and Joel and everything you guys do so I’m excited to be part of this interview. Thank you for having me. You mentioned over 20 years in software testing and my 20 year anniversary at Microsoft is coming up in just two weeks from Friday. Big, big milestone. I never thought I would ever work at any company, let alone Microsoft, for this long. It’s pretty remarkable.

    You should automate 100% of the tests that should be automated.

    The Overuse and Abuse of Test Automation

    Derrick:
    You say that “Automation is overused and overvalued in software.” Why is this and why do you think this came about?

    Alan:
    Probably for a lot of reasons. This is a traditional systems problem. I think some of the main reasons are people wanted to use, I think initially automation as a way to replace a lot of human testing. Where those two approaches really compliment each other. I still see a lot of manual test cases, or manual testing converted to automation. I’ve been at teams at Microsoft, where one of the things we tracked early on was to track the value of our test team was the manual to automation conversion. At the time I thought this just doesn’t seem right. But I was too junior to figure out what to say about it. Over time I figured out, you know what, these are actually two different kinds of testing.

    You need sort of the human… Every team has this. Especially your audience knows that these guys are just good at walking through things and going that’s not right, that’s not right, that’s not right and automation doesn’t catch any of those things. On the other hand, automation is really good for a lot of other types of testing. We just tend to in general, we, the software industry, tend to apply automation as this blanket way to do all testing when it’s really especially suited for several specific kinds of testing.

    Derrick:
    The book entitled “The A Word” focuses on the abuse and misuse of test automation in software development. What abuses and misuses have you seen?

    Alan:
    One of the abuses is I think people trying to automate too much or automating the wrong things and there’s a quote I use. I’m sure it’s in the book because I say it all the time is that you should automate 100% of the tests that should be automated. The challenge in test design is to figure out which of those tests are best suited to be automated versus this is really going to be really error prone.

    Probably the biggest abuse I’ve seen is just going crazy trying to automate too much, and even worse being very proud that you have 10,000 or 100,000 or a million automated tests when you don’t have a lot of trust over the quality of those tests or the quality of the infrastructure they’re running on or the product. I think a lot of teams get really stuck. They get… They have test failures and I believe that test failure 100% of the time should indicate a product failure. Failure of the product on your test. We all know that the first thing we look at is the test correct and did it do… What else could have gone on here? Maybe if I run it again.

    Another abuse is the test failed, I run it again, they pass. Okay, everything’s fine, which just drives me nuts because you don’t know… Something was flaky. I don’t think you even have to be anal retentive to get mad about that. I am really, really scared of flaky things because that flakiness that happens once or twice inside your walls, once you scale and deliver that to 100,000 or a million people that may happen a lot more. You want to be really careful about those. I’m just really a big fan of focusing the automation on things you can really trust and verify the automation. I think the biggest misuse, just trying to automate too much and being careless about the quality of that automation and the means of doing that.

    When to Automate a Test

    Derrick:
    When should you automate a test?

    Alan:
    When it’s necessary. My rules for automation a test, well let me draw a parallel here. I coach a soccer team of 12 year olds. One of the things I talk about, and even with 12 year olds when they’re playing defence, when we get the ball in our half, I say either clear it or make 100% pass. Meaning you clear the ball hard outside or you make the pass you absolutely is going to get to your teammate accurately where they can receive the ball. I think there’s a parallel in automation. When I… The things I want to automate is I want to be 100% confident in this test. I can write this test and I can trust the value, pass fail, 100% of the time.

    There’s going to be a caveat on that for a minute I think. We’re talking about unit test, functional test, regression test, the tests I want to run every day across hundreds of platforms. That is absolutely the right answer. I think there’s a little bit of a caveat when I want to write what I’ll call exploratory automation. I’m going to go what happens if I write a monkey test? Somebody just randomly clicks on buttons, etc. etc. etc. Just as a stress test. Totally fine. I’m not going to run that everyday on every build and trying to investigate every single failure. I’m using that to flush out some of the really tricky weird things. There’s all kinds of examples of that.

    For those tests that I want to run everyday across lots of devices, or lots of platforms I want 100% confidence that when that test passes functionality is correct and when it fails there’s a product bug that I need to go address. My heuristic for automation is I automate when I’m bored. So when I very first started at Microsoft 20 years ago, and I was actually a contractor for six months first so this was over 20 years ago. I was handed a spreadsheet full of test cases. I knew how to code. I said, I asked my manager, “When do you need these automated?” He said, “We don’t have time to automate, you just need to run these everyday.”

    I got bored about two days in and automated them anyway because I could and I could do it really quickly. I was fairly confident in my ability and I was bored. I found other things to do to fill my time. There’s always lots of work to do. I could run these automated tests and sort of a really poor man’s regression test because these lists of test cases weren’t that good anyway. I was bored. That’s one of my biggest heuristics. I was bored running the test cases. There’s a repetitive task in … I just did Lync which is now Skype for business for awhile and if I wanted to add a thousand users to see what was going to happen, I’m going to automate that. I’m never going to do that manually. I could even, I should be pretty confident that should work everyday too. So that falls into 100% category as well.

    I think when you hear the phrase ‘it’s just test code’. To me that’s a code smell

    Problems with GUI Testing Automation

    Derrick:
    While on automating things, a quote from your book says, “For 95% of all software applications directly automating GUI is a waste of time.” Why is this?

    Alan:
    I think it’s really hard to get right. I think that 100% rule I have where you can really trust those tests is very difficult. I think there’s a lot of promise with automation tools is to automate end to end scenarios. For me, I think looking at end to end scenarios is very much a great activity for humans to do. We want to see how the software works end to end. Where I have seen success with automation at the GUI level is very short tests because the longer you go the more weird things can happen and the more chance for flakiness you have in that test.

    Another reason, and I’m sorry to say this, is often we have is this, really scary when you think about it, to me at least… We often have our most junior developers, our brand new testers who are learning to code or maybe some company that’s where you start people. You get these very junior people without a lot of design knowledge for software and a lot of experience. You tell them write this GUI automation. You have junior people doing something that’s much, much harder than most people admit and it just makes it more prone for failure.

    I think when you get success is you have developers who know what they’re doing, more senior developers. It doesn’t have to be your top developer but you have experienced people who know what they’re doing. They understand design and they’re very careful about writing tests that they can trust to show product status. That’s the case that GUI automation can actually work.

    There’s a friend of mine, Chris McMahon over at Wikipedia. Every time I mention GUI automation, brings up the fact that he’s had great success doing it but the difference is Chris knows what he’s doing and knows how to be careful with it. I think a lot of people trying to write GUI automation just don’t have those skills or experience to handle the complexity of how difficult that is.

    Derrick:
    What about the 5% of cases where GUI automation does make sense?

    Alan:
    I’m sure it’s obvious to the listeners that these numbers are not based on actual data, they’re made up for me to make a point. Anecdotally, probably about right. When you’re confident that issues will… Failure is product bugs, absolutely. Regression test, very good for quick tests, not end to end. Be careful of that. I think testing those small tasks, making sure the functionality is correct so that you can do some accurate end to end sort of testing.

    I think one way to think of it is to ensure the product can be tested thoroughly by humans and those humans can be internal testers or customers versus trying to test the product end to end. I think when you try to, really when you’re trying to replace or try, you can cover all of this end to end scenarios in automation you get into trouble. I think for a series of quick tasks, verifications, making sure that the functionality across the product is correct, absolutely good places to apply automation, both at the GUI and below the GUI level.

    Good Test Design Factors

    Derrick:
    At the heart of a number of test automation issues is poor test design. What are some of the important factors to consider when designing an automated test?

    Alan:
    One is just your basic design principles for code which I think as I mentioned before when you have junior people doing that, sometimes they just don’t have that experience to apply those. One of the things I did is I was on the Xbox One team before I joined this project team at Microsoft and I was really adamant about doing something that had never been done on that team before, which is I held our test code to the exact same standards as our product code. The exact same static analysis tools, the exact same rules for code review etc. We had a really high bar for our test code. When you’re trying to ship a console to a million people and you’re trying to run massive numbers of tests across a huge number of consoles, we did not want to waste our time investigating false failures.

    I think when you hear the phrase ‘it’s just test code’. To me that’s a code smell. Whenever I hear someone say that I know I need to go dive in deeper and figure out what’s going on. Some design things, like I think one big one that I apply right away is that tests do one thing. Don’t have a test function called, you know, download app, install, and make sure it works or something like that. Have a function do one thing. For developers it’s pretty obvious. You’re writing a unit test, you usually have one assertion or maybe a few if it makes sense in the logic. You’re not trying to have one test method do a whole bunch of different things.

    Minimize your assumptions. The typical things around magic numbers for screen size or assuming that somebody will never suspend while running your app or running your test. Just minimize how many of those are and guard for those. Then one huge thing I look for in test code is really good logging on what’s going wrong.

    Another big thing I push is when there’s a test failure, I want to be able to know… Ideally I want to know what the problem is and what the fix is or what exactly what went wrong at least, from the logging. I think another social code smell for me is well let me run that again and see what happens or let me run it under the debugger. We all know how to run debuggers and we all know how to run the test again and fiddle through of what’s going on. You save a ton of time if you put that care upfront, get the right logging in place. I really push that. I think, one phrase I use here a lot is once you have to detach the bugger you lose. It just wastes too much time. I like to get that logging right the first time. Especially when we’re deploying to a lot of people and maybe we want to pull these logs from, or maybe we have a customer run a test because they have a weird thing going on. I really push accurate logging for those tests.

    In automation we just don’t leverage the power of the loop

    What Kinds of Tests Are Suited to Automation

    Derrick:
    You say that using automated tests just for regression testing is short sighted. What other types of testing is automation useful?

    Alan:
    When I look at the literature, when I talk to teams doing automation, they’re automating those functional scenarios, end to end things that we’ve already talked about but one of the areas I think a lot of teams miss is using automation for what I called earlier exploratory automation. Writing that quick perf test. You don’t need to be a perf expert and figure out what are our deltas and deviations and all these things, but it’s as a nice perf stress test, I’ll use the Skype example I gave earlier is what happens when I add 1,000 contacts? I can just write a quick little test that there’s a snapshot of memory. Add 1,000 contacts, checks memory, okay, looks good. Really that’s maybe 15 minutes to write that code. Probably faster if you already have some frameworks in place.

    It’s a very valid test, and then I can think of how about I connect to a call and disconnect. Again very short steps, but I think we err towards, again it’s a general we. We err towards trying to hit those user scenarios versus the things that automation and programming are great for are looping and do things a whole bunch of times seeing what happens. I think we lose a lot of value by not going oh yeah, this is a thing that’s really awful and impossible to do by hand but easy and fun and quick and often valuable to do using code. I found a lot of times in automation we just don’t leverage the power of the loop.

    Recommended Resources

    Derrick:
    What are some useful resources for those wanting to learn more about a holistic approach
    to software tests?

    Alan:
    My favorite book, and I said this many times before on sort of the functional testing part… This is good for developers as well as testers, like kind of getting into the idea of everything from the basics of functional testing, beyond unit testing, but functional testing to even getting into model based testing a little bit is Lee Copeland’s book “Practitioners Guide to Software Test Design” I always like that for a beginning book. It’s very quick and to the point and Lee’s kind of a funny guy. There’s some humor in there. It reads really well for me. On the other end, for thinking more about the systems thinking part of what software testing is, sort of the philosophical side is Jerry Weinberg’s book “Perfect Software and Other Illusions”. It kind of gives you that other end of it.

    In between, there’s another line I use, not in the book. It said, when I first started studying software testing I read one book and thought I knew everything, and then I read another book and was confused. It wasn’t until I read my third, fourth, and fifth book and started reading blog posts and articles that I began to form my own opinions. There is so much out there and you don’t learn what to throw away I think until you begin to form your own opinions.

    Derrick:
    Thank you so much for taking your time to join us.

    Alan:
    It was a lot of fun. Thanks for having me.

    by Gareth Wilson at May 27, 2015 09:47 AM

    Bret Victor

    The Web of Alexandria (follow-up)

    A follow-up (disambiguation? expansion?) regarding The Web of Alexandria.

    by Bret Victor at May 27, 2015 02:33 AM

    May 26, 2015

    John Udell

    Training and bug reporting should be part of every app

    People aren't good at reporting software bugs. Moreover, software isn't good at self-reporting -- particularly when it's browser-based software. These conversations happen every day:

    User: The new Frobinator isn't working anymore.
    Developer: What did you do, what did you expect to happen, and what did happen?
    User: I clicked on the Frobinate button, I expected it to work, it didn't.
    [ Also on InfoWorld: Get real about user security training." | Get a digest of the day's top tech stories in the InfoWorld Daily newsletter. ]

    We've all been there. Frobinate, let's say, was supposed to populate a widget with data. Maybe it found no data at all; maybe it found the wrong data. Maybe the widget never appeared. Whatever the problem may be, we have to be able to reproduce it in order to address it.

    To read this article in full or to leave a comment, please click here

    by Jon Udell at May 26, 2015 10:00 AM

    Tim Ferriss

    FacebookTF_poker1

    Try this morning tea cocktail instead of coffee. It’s rocket fuel for the brain.

    I started experimenting with fat-plus-stimulant beverages in 1998 and 1999 while on the Cyclical Ketogenic Diet (CKD). For the above tea blend, I now add turmeric and ginger to the aged pu-erh, usually Rishi brand.

    The above video was shot while filming the parkour episode of The Tim Ferriss Experiment TV show. We filmed 13 episodes back-to-back and I needed a morning pick-me-up that could be prepared quickly but sustain me for hours.

    The tea prep might seem reminiscent of Bulletproof Coffee, and it is.  They serve similar purposes.  For this reason, I jokingly referred to the cocktail as “Titanium Tea” with the production crew.

    Alas, BP coffee looks like a delicious frappuccino, and my concoction looks like diabetic horse urine.

    Here’s why I still drink TT Horse Urine nearly every day:

    • I’m a caffeine “fast metabolizer” according to genetic test results from 23andMe, Navigenics (since acquired), and personal experience. If I drink a cup of black coffee, I feel like a superhero for 30 minutes, then need two cups to get back to baseline. But…
  • When I use a blend of — say — green tea and fermented black tea, I’m combining slightly different pharmacokinetics and biological half-lives, so respective peak plasma (blood) concentrations of stimulants and other compounds are staggered. Instead of one single high point and then a rapid descent into fatigue, I have multiple high points. Rather than feeling amazing for 30 minutes and then fatigued, I can feel 20% more effective for 3-4 hours.

  • This can be extended further if I include a tea like yerba mate (I like Cruz de Malta), which includes three xanthine alkaloids. For our purposes, you can think of these three xanthines as “stimulants”: good old caffeine (by weight, often <50% compared to coffee), theophylline (found in green tea), and theobromine (the primary alkaloid in cocoa and chocolate). Yerba mate isn’t the only tea to include these three, but the ratios in yerba mate appear optimal for my biochemistry and creative writing.

  • NOTE: The most extended effect is only achieved if you sip the yerba using traditional technique. The gourd is my constant companion — plus one glass of Malbec — for 10pm-4am jam sessions when on book deadline. Just as coca-leaf teas don’t = cocaine, which doesn’t = crack, the form and speed of administration matters. For the nerds, this is why powdered “good” foods (e.g. bean flour) aren’t always compliant with the slow-carb diet.

  • If I rely on theobromine and/or theophylline as my uppers, instead of primarily caffeine, I can quit stimulants cold turkey without caffeine-withdrawal headaches. This can be a massive competitive and health advantage, as you can cycle off of stimulants to minimize tolerance development.

  • But — I’m not a doctor and don’t play one on the Internet! As always, the dose makes the poison. Excessive theophylline and theobromine have plenty of adverse effects, particularly when consumed with fat like coconut oil (i.e. “dose dumping“). So speak to your doc first if you have any medical conditions, m’kay?  This is an N=1 article.

  • I still drink coffee on occasion, especially if empty handed in the middle of nowhere. It’s a hell of a lot easier to find coffee and butter than pu-erh tea and coconut oil. Definitely 10x better than straight black coffee, and kudos to Dave Asprey for taking it mainstream. It’s now ubiquitous, and that’s no small feat. Many of the top performers I know drink BP coffee, including legendary producer Rick Rubin.

  • For more quick-tip videos like the above, click here.

    For 13 full-length episodes shot by an Emmy award-winning team, click here or on the image below.

    FacebookTF_poker1

    by Tim Ferriss at May 26, 2015 03:11 AM

    May 25, 2015

    Bret Victor

    The Web of Alexandria

    Vannevar Bush's "library of a million volumes, compressed into one end of a desk" may sound quaint to us today. Bush naively assumed that immediate access to a million volumes would require the physical presence of those million volumes. His proposal -- a million volumes in every desk.

    by Bret Victor at May 25, 2015 01:00 AM

    May 24, 2015

    Blaine Buxton

    Getting a USB sound card configured for Raspberry Pi 2

    I recently tried to get a USB sound card working on a Raspberry Pi 2. My motivation was to start working on audio applications like writing my own synth. It's something I've wanted to do for a long time, but some odd reason never got around to it. At first, I simply tried to output sound via the built-in sound card. This experiment was successful of course, but there was a lot of noise in the output. I tested using the SonicPi program that comes with the Pi.

    My next experiment was to use a USB sound card that I had gotten for cheap. Apparently, these are hit and miss and if I were to do it over again, I would get one from Adafruit where they sell ones that have been tested for the Pi. Everything worked out so I lucked out, but the path to success was not obvious. For your information, I used the CMedia HS100 from NRGtech. I also used the latest version of Raspbian (Debian Wheezy) and updated my pi firmware with "sudo rpi-update" before I even started since most guides mentioned to do this for latency.

    Before I begin, I was repeatedly given the ALSA (Advanced Linux Sournd Architecture) document. There's a lot of information in there. I hope to spend sometime read it more thoroughly, but when you're trying to get something simple working, it's like drinking from a fire hose.


    1. Plugin the USB sound card.
    2. Navigate to the Menu>Preferences>Audio Device Settings.
    3. At the top of the dialog, there is a drop down for the sound card. Mine displayed "bcm2835 ALSA mixer) (Default)". Click it and you should see your new USB sound card. Again, mine displayed "USB PnP Sound Device (Alsa Mixer)".
    4. Select the USB sound card.
    5. Click "Make Default" button.
    6. You can click "Select Controls..." which brings up a dialog for you to be able to select things it can use to change settings on your sound card. I selected everything.
    7. Make sure volume is up and USB soundcard is connected to either headphones or speakers. To verify, my speaker setup, I used the built-in audio output first before connecting USB sound card.
    8. Edit /etc/modprobe.d/alsa-base.conf with your favorite editor (sudo vi /etc/modprobe.d/alsa-base.conf). I strongly recommend making a backup of this file. You can also follow this from an Adafruit article as well.
    9. Find the line "options snd-usb-audio index=-2" and change it to "options snd-usb-audio index=0".
    10. Add another line below the edited line: "options snd_bcm2835 index=1"
    11. Save the alsa-base.conf and reboot the pi (sudo reboot).
    12. speaker-test -c2 -D hw:0,0. This should work. You will hear white noise from left to right on your speakers.
    13. aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
    14. Success? Or did you get "Channels count non available". If success, you can stop now and celebrate. Have some fun with SonicPi!
    15. sudo aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav
    16. This probably worked. If so, the answer is simple. Edit the $HOME/.asoundrc (vi $/.asoundrc). Back up the original is again strongly recommended.
    17. Clear the existing contents of the .asoundrc.
    18. Add "defaults.ctl.card 0"
    19. Add "defaults.pcm.card 0"
    20. Add "defaults.pcm.device 0"
    21. Save .asoundsrc. Try "aplay -D hw:0,0 /usr/share/sounds/alsa/Front_Center.wav" again.
    22. Success? Excellent. Glad this guide can help. If you are still having issues: this article and this one too helped me figure out what was going.
    I wrote this guide up mainly for myself so I don't forget it and to use again. Hope it helps you as well.

    by Blaine Buxton (noreply@blogger.com) at May 24, 2015 06:02 PM

    Giles Bowkett

    May 21, 2015

    Fog Creek

    FogBugz Gets the Full Spa Treatment

    With almost 15 years of trusty and reliable service, we decided it was time to pamper FogBugz a little. And what better way to do that than with a full spa treatment.

    Now you might be thinking “Whoa! 15 YEARS!”, and you’re absolutely right, that’s a lot of time. Especially if you consider that Internet years are pretty much like dog years. Amiright?

    We’re incredibly lucky to have such loyal customers who have been using FogBugz for a super long time and are used to how FogBugz looks and feels. So as you can imagine, whilst we knew it was time to make changes, we had to be careful and subtle.

    We started with the two most visited views in FogBugz: a warming exfoliation to the List Page and a bespoke massage to the Case Page. Here’s how they’ve been refreshed:

    The List Page: before & after
    before-after_list

    The Case Page: before & after
    before-after_case

    We softened up the edges here and there and we updated our icon system too, making things easier on the eye. But most importantly, we made your content and your cases easier to read and skim through.

    We hope that these changes improve your experience while using FogBugz and give you the warm, tingly feeling of a Bee Venom face mask (it’s a thing, apparently) as you resolve your cases.

    But our treatment didn’t stop there. As you may have also seen, we’ve been giving some love to other areas of FogBugz lately too. Like the new User Options page, in-app notifications and activity feed as well as improvements to the Filters menu. Not to mention the release of Iteration Planner, adding support for your Agile and Sprint Planning needs.

    Design is never done and FogBugz is no exception. Even after 15 years, we’re still working on making FogBugz the best issue and bug tracker in the world.

    Now, who’s up for an ultimate holistic skin therapy treatment?

    by Enrique Sánchez at May 21, 2015 06:56 PM

    Lambda the Ultimate

    Composite Replicated Data Types: eventually consistent libraries as non-leaky abstractions

    Composite Replicated Data Types
    Alexey Gotsman and Hongseok Yang
    2015

    Modern large-scale distributed systems often rely on eventually consistent replicated stores, which achieve scalability in exchange for providing weak semantic guarantees. To compensate for this weakness, researchers have proposed various abstractions for programming on eventual consistency, such as replicated data types for resolving conflicting updates at different replicas and weak forms of transactions for maintaining relationships among objects. However, the subtle semantics of these abstractions makes using them correctly far from trivial.

    To address this challenge, we propose composite replicated data types, which formalise a common way of organising applications on top of eventually consistent stores. Similarly to a class or an abstract data type, a composite data type encapsulates objects of replicated data types and operations used to access them, implemented using transactions. We develop a method for reasoning about programs with composite data types that reflects their modularity: the method allows abstracting away the internals of composite data type implementations when reasoning about their clients. We express the method as a denotational semantics for a programming language with composite data types. We demonstrate the effectiveness of our semantics by applying it to verify subtle data type examples and prove that it is sound and complete with respect to a standard non-compositional semantics

    May 21, 2015 03:29 PM

    May 20, 2015

    Tim Ferriss

    TF-StitcherButton

    Danielle Teller and Astro Teller on the Tim Ferriss Show

    [Preface: Would you like to sponsor The Tim Ferriss Show, the #1 business podcast on iTunes and one of the iTunes “Best of 2014″? Click here for details.]

    Dr. Astro Teller is a computer scientist and entrepreneur who currently oversees Google[x], Google’s moonshot factory. Dr. Danielle Teller is a physician specializing in intensive care and lung medicine; she has trained doctors and run research programs at Harvard University and the University of Pittsburgh.

    Together, they are the authors of Sacred Cows.

    In this conversation — my first podcast with a couple — we cover a lot of my usual questions (favorite books, routines, philosophies of living, etc.) but focus on something I haven’t personally figured out: relationships.

    It’s important to note that the Tellers are not “for” marriage but, rather, “for” the freedom to decide how to live most honestly and happily, whether as part of a couple or as a single person.

    Combining the rigor that has established them as leaders in their respective fields, Astro and Danielle walk me through how they think about relationships, and how they survive and thrive as two driven people.

    Sidenote: Want to see me tackle dating experiments, struggle with live “cold approaches,” and optimize online dating with a computer hacker? Be sure to watch my “Dating Game” episode of The Tim Ferriss Experiment here.

    Enjoy the podcast below!

    TF-ItunesButtonTF-StitcherButton

    This podcast is sponsored by LSTN Headphones. LSTN Headphones are gorgeous headphones that I use. They’re made of real exotic, reclaimed wood. Proceeds from each purchase help a hearing-impaired person hear for the first time through the Starkey Hearing Foundation. Here are some of the headphones I wear and travel with: LSTNHeadphones.com/TimOn that page, use the code “TIM” to get $50 off orders of $99 or more!

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for the 4-Hour Body? Here are some of the impressive resultsClick this link and get a free $99 upgrade. Give it a test run and share your results!

    QUESTION(S) OF THE DAY: Are you pursuing monogamy? Why or why not? Have you figured out other rules that work for you and your partner? Please (seriously, please) let me know in the comments! I expect this thread will have some great suggestions.

    Scroll below for links and show notes…

    Do you enjoy this podcast? If so, please leave a short review here. It keeps me going…

    Subscribe to The Tim Ferriss Show on iTunes.
    Non-iTunes RSS feed

    Selected Links from the Episode

    Get the Book on Amazon | Google Play | AstroTeller.net| SacredCowstheBook.com | TEDxBoston

    Recipe for a Monogamy Cocktail

    • 3 Parts Rosemary-Infused Vodka
    • 2 Parts Vanilla-Infused Cognac
    • 1 Part Lemon Juice

    Show Notes

    • A little bit about the work of Astro and Danielle [6:30]
    • Thoughts on the usefulness of a long-term plan [11:30]
    • Deconstructing how Astro and Danielle approach challenges and plans [12:35]
    • Exploring the “soulmate” concept of one true love [15:50]
    • Differentiating between true love and society’s view of marriage and divorce [19:30]
    • New ways of seeing marriage and creating space from social pressure [22:45]
    • Why Astro and Danielle decided to get married for a second time [28:44]
    • Thoughts on fear factors [31:00]
    • The reasons for getting married in authentically happy couples [34:20]
    • The most common mistakes type-A men make in large relationship decisions [36:20]
    • How Danielle and Astro first met [39:35]
    • Exploring my own fears of losing at the game of marriage [41:45]
    • How Danielle and Astro view conflict resolution in their marriage [46:30]
    • Family rituals of Astro and Danielle [50:35]
    • How Astro and Danielle think about managing spouse and children relationships [55:35]
    • The worst advice for “significant other” relationships [56:50]
    • Do you know single people older than 40 who are authentically happy? [59:55]
    • The most impactful $100 for Danielle and Astro [1:08:50]
    • Favorite/most-gifted books [1:13:35]
    • Who is the first person who comes to mind when you think “successful”? [1:19:30]
    • If you could ask anyone from all of history 100 questions about anything who would you choose? [1:22:05]
    • Ways in which medical/scientific training has helped with family relationships [1:23:15]
    • How Astro Teller thinks about death and how to live life intensely every single day [1:31:30]
    • How Danielle Teller measures the success of a day [1:40:15]

    People Mentioned

    by Ian Robinson at May 20, 2015 08:01 PM

    Mark Bernstein

    Feed

    This 2010 series-starter and Hugo nominee is not without shortcomings. It’s another zombie apocalypse and, knowing itself late to that party, doesn’t always take its zombies seriously. It’s a power fantasy about preternaturally smart and capable teenage bloggers who are so competent that we usually forget they’re teenagers. The early chapters have barrels of exposition once we get past the stock James Bond opening chase, and minor characters are frequently reduced to their function, which leaves the world thin. The core technical problem of the YA quest – how do we get agency in the presence of parents? – is settled here by establishing a pair of (very interesting) parents and then failing to even think of them for weeks on end. Much of the science fiction – the world of 2040 where bloggers dominate new media news – was already coming true by the time the book was published, and our hero’s amazement at her sysadmin’s ability of spin up virtual servers as needed is terribly 2008. Finally, this is a book about politics, but its politicians are not very well drawn and their politics is indistinct; I can believe we’ll have viral zombification in 2040 but I’m really skeptical that we’ll have liberal Republicans.

    There’s a lot of wish fulfillment here. In the future, not only are weblogs a dominant and profitable medium, but every A-List blog employs a department of “fictionals” to fill the audience’s demand for stories – and poetry! When our heroes need to hire a head fictional, they find a simpatico young blonde who happens to be a terrific sysadmin and who wants them to call her “Buffy”.

    And yet, there really is something here. There’s a competent thriller eventually, sure, but beyond that there are vistas of real strangeness. These are children born after the end of the world. They expect to die, because that happens a lot in their world. They expect to do amazing things because they were brought up that way and that’s who they are. They don’t spend much time mourning the lost, zombie-free world. They’re out to ride fast bikes, fight off zombie attacks, buy cool equipment, and manage their site’s chat boards and merchandising. They do that well, and, in the intervals, they get out the news, poetry on deadline.

    May 20, 2015 03:31 PM

    Dave Winer

    What would you do if you woke up one morning and there was no Internet?

    I asked this question on Facebook and Twitter, and got a variety of answers.

    I think there are two "correct" answers.

    1. Start a new Internet.

    2. Cry.

    Most people say they would go do normal things that don't involve the Internet, but I think the world would take a long time to adjust. Many of us remember a world without the Internet, but we don't remember a world without the Internet that used to have the Internet.

    A question that reveals the problem is to wonder what would happen if you woke up one morning and found there was no electricity. Not much would happen in the world as it's currently configured without electricity, even though there was a time when it worked fine without it.

    I think the Internet is sufficiently integrated into our civilization at this point that if it were to be removed, it would be such an enormous shock to our economy that.. well, that's why #2 is also a correct answer.

    I'd like to think we could quickly boot up a new net. That's more likely than rebooting electricity because a lot of people who built the initial Internet are still alive and would know how to layer things so it could come back pretty quickly. Assuming the electric grid isn't dependent on the Internet. Which is itself a good question.

    May 20, 2015 12:08 PM

    Fog Creek

    dev.life – Interview with Michael Fogus

    In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

    Today’s guest is Michael Fogus, Software Architect at Cognitect. He’s a contributor to Clojure and ClojureScript and author of ‘The Joy of Clojure‘ as well as ‘Functional JavaScript‘. He writes about life, programming and thinking on his blog.


    Michael Fogus
    Location: Washington, DC, US
    Current Role: Software Architect at Cognitect

    How did you get into software development?

    I was privileged to receive a Commodore 64 when I was 8 years old and it was my only computer for the next 10 years. Most of the time, I used it only to play games, but I definitely coded my share of BASIC programs (even one that was self-modifying). I remember one time my best friend and I stayed up all night typing in a canoeing game from an old computer magazine (back when they actually contained source code) and when we were done we tried running it and of course it didn’t work. The frustration was exquisite. After a half-hearted attempt to try getting it to work, we gave up and went to bed. Little did I know that I had just experienced what it was like to be a working programmer. My final projects on that lovely computer were my college entrance essays.

    I originally went to school with the intent of majoring in Philosophy and Mathematics. However, in my second year my college started a Computer Science program from scratch and I decided to take a few classes. My curriculum was based almost entirely on XLISP and Common Lisp, and I fell in love with both. I suppose you can say that the rest is history. I was one of the first students (of two) to receive a Computer Science degree from my college. Sadly I needed to stay another year to get the Philosophy degree, so I instead jumped ship and went into the (so-called) Tech industry.

    After a few years of doing CLIPS, Delphi, C, and C++ programming I switched to Java and did that for a very long time. I also took graduate courses during that time in AI working mostly in Common Lisp, Scheme, and Prolog and the contrast between the day job and course work was not in my favor. I eventually broke down and pushed for projects that were relevant to my graduate work and was fortunate enough to land on some great projects. From machine vision to expert systems development and autonomous agents to distributed simulation. I got a nice sampling of the professional “AI” landscape. I did that kind of work for a long time before discovering Clojure and Datalog and the kind of work that I’m doing currently.

    comm64 (1)

    Tell us a little about your current role

    Most of the projects that I consult on are some kind of web service backed by a distributed architecture. The fashionable term is “microservices,” but in my distributed simulation days we called them “federates” – though they tended to be more coarse-grained back then. What happens on a typical day depends on the project team that I’m working on. In any case, 99% of my time is spent remote. I’ll only say that flexibility is a virtue.

    At Cognitect, I’m currently working as a consultant with a company that has the largest Clojure codebase that I’ve ever worked with. My niche with Cognitect has been to work with companies that are looking to use Clojure to build their business, or with companies that have existing Clojure code and would like a thorough code and/or architecture review, or that need a “mentor.”

    On Fridays, I’m free (as in freedom) to work on open-source projects and recently the majority of that time has gone toward getting Clojure 1.7 released. Lately, I’ve been screening patches which is a wholly thankless job, but one that I find challenging and that allows me to get a better grasp of the features and bug fixes in the pipeline.

    Besides my work on Clojure (and rarely ClojureScript), I have been toying around with little programming languages, libraries, and the toy databases to explore interesting ideas. I call these “code paintings.” The biggest challenge in doing these one-shot projects is that I can take them too seriously sometimes, when in reality they’re meant as a form of play.

    When are you at your happiest whilst coding?

    Programming is the only activity that I’ve ever done that’s compelled me to jump out of my chair, yelp, and pump my fist into the air while completely alone in an empty house. I guess whatever provokes those reactions is when I’m happiest. Though working at home allows me to write code while singing some Violent Femmes or the theme song to Raising Arizona, so those times are nice too.

    raisingArizona (1)

    What is your dev environment?

    My development environment is pretty humble these days. Though I do have a nice MacBook Air with dual monitors and OSX for my workspace, I tend to spend most of my time in Emacs writing Clojure. I would have a hard time divorcing myself from Emacs at this point, but truly my most important software tools are my pen (a hacked G2 pro) and notebook (Tops quad ruled lab book). I would literally (in the modern sense) die without my notebooks.

    What are your favorite books about development?

    In no particular order:

    • ‘Out of the Tarpit’ by Marks and Moseley
    • ‘Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I’ by McCarthy
    • ‘LISP 1.5 Programmer’s Manual’ by McCarthy, Edwards, Hart, and Levin
    • ‘META II: A Syntax-oriented Compiler Writing Language’ by Schorre
    • ‘Reasonable LISP’ by Queinnec
    • ‘Open, Extensible Composition Models’ by Piumarta
    • ‘An Association-based Model of Dynamic Behavior’ by Piumarta
    • ‘Open, Extensible Object Models’ by Piumarta and Warth
    • ‘STEPS Toward The Reinvention of Programming’ VPRI
    • ‘The Fundamentals of New Computing’ mailing list
    • ‘The Influence of the Designer on the Design – J. McCarthy and LISP’ by Stoyan
    • ‘Wabi-sabi for Artists, Designers, Poets, and Philosophers’ by Koren (thanks, Sam!)
    • ‘How Buildings Learn: What Happens After They’re Built’ by Brand
    • ‘The Art of the Metaobject Protocol’ by Kiczales
    • ‘Thˆe Early History of Smalltalk’ by Kay
    • ‘Smalltalk-72 Instruction Manual’ by Kay and Goldberg
    • ‘To Trap a Better Mouse’ by Piumarta
    • ‘Are We There Yet?’ by Hickey
    • ‘The Language of the System’ by Hickey
    • ‘Growing a Language’ by Steele
    • ‘Systems that Run Forever Self-heal and Scale’ by Armstrong
    • ‘Programming Should Eat Itself’ by Amin
    • ‘Complex Information Processing: A file structure for the complex, the changing, and the indeterminate’ by Nelson
    • ‘The LISP70 Pattern Matching System’ by Tesler
    • ‘Derivability, Redundancy, and Consistency of Relations Stored in Large Data Banks’ by Codd
    • ‘A Relational Model of Data for Large Shared Data Banks’ by Codd
    • ‘Extending the Database Relational Model to Capture More Meaning’ by Codd
    • ‘Ideal Hash Trees’ by Bagwell
    • ‘Production Matching for Large Learning Systems’ by Doorenboros
    • ‘Soft Stratification for Transformation-Based Approaches to Deductive Databases’ by Behrend
    • ‘Practical Predicate Dispatch’ by Millstein
    • ‘Flavors: Message Passing in the LISP Machine’ by Weinreb and Moon
    • ‘Predicate Dispatching: A Unified Theory of Dispatch’ by Chambers
    • ‘Worlds: Controlling the Scope of Side Effects’ by Warth and Kay
    • ‘BEINGS: Knowledge as Interacting Experts’ by Lenat

    I’d love to fit all of these ideas into a programming language one day.

    What technologies are you currently trying out?

    • 1. Erlang
    • 2. Quadcopter drone
    • 3. SML
    • 4. Everything else under the sun

    quadcopter (1)

    When not coding, what do you like to do?

    I like to read, and I read a lot. When I’m not reading I play Baseball, tabletop board and card games, dabble in designing the same, and occasionally make music (if you call that screeching that comes out of my face music).

    What advice would you give to a younger version of yourself starting out in development?

    You don’t know what you’re talking about!

     

    Thanks to Michael for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

    Recent dev.life Interviews

    Peteris Krumins
    Peteris Krumins
    Eric Lippert
    Eric Lippert
    Chris
    Chris Hartjes
    Paul Jones
    Paul M. Jones

    by Gareth Wilson at May 20, 2015 09:09 AM

    May 19, 2015

    Fog Creek

    Welcome Back, Project Groups!

    Ladies and Gentlemen, it is with great pleasure that we announce the long awaited arrival of Project Groups in FogBugz On Demand!

    Project Groups are a way to organize your Projects together in FogBugz so that it’s easier to search and filter by multiple Projects at once. This feature was previously available as a plugin but is now available for all, so long as you’ve switched to the new, shiny and fast FogBugz UI. If you’ve been holding off, then now’s the time to upgrade (and if you’ve been using the plugin, then all the project groups you’ve already defined will come with you)!

    Here’s a little more about how Project Groups can help you to be more productive:

    Let me tell you a story. A true story… ok, perhaps it is more of a realistic story*.

    *Any resemblance to real persons or actual facts is purely coincidental.

    Katyusha and the Neverending Search String

    Katyusha recently signed up for a FogBugz On Demand account. She works as a freelance software consultant. She is hard-working and loyal, so she has many repeat clients. She usually has about four or five clients at one time, each with multiple projects and she likes to keep past projects around for later reference.

    However, Katyusha noticed that there was no obvious way to group Projects together. She resolved to have one or more manual filters for each client, made of very long Search For queries, like:

    project:"Dogebot" OR project:"Doge-o-matic" OR project:"Wow" OR project:"Very Project"

    This worked but was a real pain to maintain. Every time she started a new project for a client, she had to manually update all of the filters’ Search For values.

    But now with Project Groups, Katyusha woes have come to an end. She can now just create a Project Group.
    groups

    This means she doesn’t need the ugly Search For strings anymore, and instead can make use of Project Group filters. She can even make rapid queries using the projectGroup search axis. For instance:
    search
    This will give her the same set of cases of the neverending search string above.

    So Katyusha, FogBugz and her clients lived happily ever after. The End.

    Nice ending, isn’t it? All stories should end so well!

    So, wait no longer and join Katyusha: sign up or upgrade to the new FogBugz On Demand!

    by Emanuele Tamponi at May 19, 2015 03:33 PM

    Giles Bowkett

    Update re Live Electronic Music Performance Design

    Last year, I wrote about an idea I had — a way to bring back some elements of classic raves and see those elements survive better. Over the years, rave music has done incredibly well, while rave events have almost been crushed by governments. The difference is, at a concert, the artists are special and the audience is there to see them, while at a classic rave, things were set up for the dancers first and the DJs second.

    My design was a hybrid of a concert, a rave, a hippie drum circle, and a video game arcade. A performer plays drums in the center, while audience members can play along in little drum pods scattered in a circle around the performer. All the drums are electronic. They play sounds like a normal drum, but they also trigger video software. Thus the "audience" plays a part in creating the event.





    Contrast this with the amazing setup the Glitch Mob uses to perform live:



    I love this and hate it too. It's excellent work. It's beautiful. It's badass. It incorporates, updates, and adapts Japanese taiko drums while still remaining respectful of the original source material — a balance which artists often get wrong. But it's still 100% about the artists being special and the audience being there to see them, which to me seems much more like a rock concert than a club or a rave.

    Also, at one point in the video, one of the Glitch Mob's shocked that a Hollywood set designer can draw, which is kind of ridiculous, because that's the job. And as a programmer, there are moments which seem silly too, because they wrote custom software, but all it seems to do is function as a bus for controller input. In the age of Overtone and Quil, that's kind of a letdown, especially given the stuff other artists are doing with custom software.

    Anyway, back to my own design: in addition to these little 3D sketches. I also wrote a basic version of the software I had in mind. My drumming in this video is terrible, and so is the software, really, but it illustrates the basic idea. Hitting the drums triggers color changes in computer-generated visuals.



    I've been outdone in this category as well. This is a promo video for the Critter & Guitari Rhythm Scope, an analog video synthesizer which responds to sound:



    The interesting thing about this, to me, is that it's analog rather than digital.

    Speaking of which, the performer in my design had a strobe light attached to their drum set. It's the little black box with a grey mesh:



    I bought a strobe light and attempted to integrate it with my electronic drum kit using a protocol called DMX. Got absolutely nowhere, although I found some existing solutions in Ruby and Node (using both CoffeeScript and JavaScript).

    But I've discovered that a small company in Italy makes a Eurorack solution for this, which links DMX to CV instead of MIDI. (Rolling your mouse over the bottom of the video brings up an audio control, although this rather stupidly assumes you're on a computer, not a phone or a tablet.)



    More news as events warrant.

    by Giles Bowkett (noreply@blogger.com) at May 19, 2015 08:19 AM

    Blue Sky on Mars

    Just Don’t Hire 0x Engineers

    During one of my philosophy courses at school, my professor gave us an in-class assignment:

    For the next five minutes, I want you to think about literal Hell. What would it be like? What would you feel and experience?

    And we sat and contemplated what Hell would be for each of us. And then we discussed it. Lots of fire and brimstone. Torture. Pain. It was a pretty lovely discussion.

    Then he flipped it on us:

    For the next five minutes, I want you to think about literal Heaven. What would it be like? What would you feel and experience?

    Surprise, surprise: this was a really shit way to spend five minutes. You first think cool, I get to see all my dead friends and family again. But then you wonder what age they’d all be. And then like, even your BFF is kind of an asshole to you sometimes, do you really want him there? But you also don’t want everyone being complacent zombies all the time- that’d be no fun either. So maybe you just imagine a non-stop orgy and MDMA bender. But wouldn’t that get boring sometimes, too? Variety is the spice of the after-life, after all.

    After about a minute of this we all just got bored. But he made us sit there and think about this for the full five minutes. It was surprisingly maddening. This was supposed to be Heaven, dammit. Eternal happiness. This should be easy.

    It turns out, it’s much easier to focus on avoiding pain than it is to envision pleasure.

    The 10x A-Player Rockstar Engineer

    The hip thing nowadays is that your software company should hire only A-players instead of B- or C-players, or focus on engineers that are ten times better than anyone else. Whether or not that’s true is debatable and dependent on how you're able to measure it, but I think the sentiment itself is the wrong question to ask.

    A Hipster Cat

    Their About page may say otherwise, but — drumroll, please — the average company is pretty average. Not everybody can hire exclusively top-tier people. And you know what? That’s fine. Quality of individuals is only one part of what makes an organization great. Sports is rife with examples of the nimble, well-connected team triumphing over the team of individual superstars.

    When I worked at Gild, it became pretty clear that while nearly all companies boasted that We only hire A-players!, the reality was that most of the companies using our hiring software were most interested in finding people that don’t suck. They wanted good people that they didn’t need to pay the top 1% of salary in the world for. It’s pain avoidance rather than pleasure seeking behavior. It’s worrying about Hell rather than trying to get to Heaven. Basically, most people were Billy Beanes rather than Steve Jobses.

    None of this is bad. What I think is bad is that there’s so much pride and focus on The Best of the Best of the Best, With Honors. It’s setting a pretty fucked up expectation for our industry.

    Not everything a Michelin

    This is an interesting tendency that can occasionally cut across a lot of different areas in your product.

    A few years back I had just landed in Amsterdam and was desperately looking around for breakfast. I checked Foursquare and saw that two of my friends had eaten at a small place just up the block. I figure they must have done at least some research to go there, so it probably wasn't terrible. I ended up eating there and it was perfect. It wasn’t a Michelin star restaurant, because I didn’t need something amazing; all I wanted was to avoid eating shitty food.

    When we’re building product, we tend to use words like best, perfect, optimized, and other top-tier words like that. That’s fine; certainly you want to help your user out as much as possible.

    But with whatever you’re building, step back and realize that sometimes quick is better than best. Or flexible might be better than optimized.

    Sometimes people just want a greasy burger.

    May 19, 2015 12:00 AM

    May 18, 2015

    Mark Bernstein

    Scott Rosenberg

    Scott Rosenberg on links: Will Deep Links Ever Be Truly Deep?

    Every time a writer or speaker creates a project by laying out ideas in a program like Tinderbox, DevonThink, Scrivener, Workflowy, Evernote, or [your favorite here!], she is living out a little of Bush’s Memex dream.

    May 18, 2015 10:17 PM

    Tim Ferriss

    Tim Ferriss

    This short video might blow your mind.

    Using household items like paper clips or toothbrushes, you can easily defeat 70-80% of the padlocks out in the world.

    The teacher is Kevin Reeve of OnPoint Tactical. Kevin has trained and consulted for the FBI, Secret Service, SWAT, and elite military units like Marine Force Recon, SEAL Team 6, etc.

    He was also my teacher for the “Urban Escape and Evasion” episode of The Tim Ferriss Experiment, which is currently the #1 non-fiction TV show across all of iTunes.

    In that episode, Kevin teaches me (and therefore you):

    • How to escape common restraints like zip ties and handcuffs.
    • How to “borrow” cars in emergency situations.
    • Effective evasion tactics for urban environments (e.g. parking garages, fast appearance changes, etc.).
    • And much more…

    I get restrained, hooded, thrown in a trunk, and subjected to other abuse. My (least) favorite part was getting stun gunned while temporarily blinded. Surprise, Ferriss!

    If you’ve ever fantasized about being Jason Bourne — or simply being ready for anything — the entire episode is full of effective and easy-to-learn techniques.

    I suggest getting the “Season Pass” for $14.99 or so, which gets you all 13 episodes for ~40% off, plus hours of bonus footage. Many of you have said that the bonus footage alone is worth more than the $15.

    MORE ON THE TV SHOW

    Bestselling author Tim Ferriss (“The world’s best human guinea pig.” – Newsweek) pushes himself to the breaking point, attempting to learn notoriously punishing skills–surfing, parkour, professional poker, Brazilian jiu-jitsu, online dating (Ha!), learning languages, etc.—in just one week each. Filmed and edited by the same team behind Anthony Bourdain’s hit shows (Zero Point Zero).

    In every episode of The Tim Ferriss Experiment, Ferriss partners with the world’s best and most unorthodox teachers (Laird Hamilton, Marcelo Garcia, Stewart Copeland, etc.), who train him for a final gauntlet. Shocking breakthroughs, injuries, epiphanies, and disasters ensue. In cases where he succeeds, Tim shows you how to replicate his results. The mantra of the show is “you don’t need to be superhuman to get superhuman results…you just need a better toolkit.”

    Enjoy!

    by Tim Ferriss at May 18, 2015 07:39 PM

    Mark Bernstein

    How Not To Crash

    A series from Brent Simmons on How Not To Crash. Part 2: don’t enumerate mutable collections, because no one’s that smart. Good advice.

    Obviously, you’d make an exception for really huge collections, collections so big that the copy is expensive. But in that case, you probably don’t want to be enumerating the collection in the first place, not if you can help it!

    You might also be wondering about small collections enumerated in tight loops. You’d be wrong. Either the outer loop is small, in which case the copies don’t cost much, or the outer loop is not small, in which case your operation is at least quadratic and you’re probably headed for trouble.

    May 18, 2015 02:44 PM

    John Udell

    For remote collaboration, Google Apps still can't be beat

    If you work in tech, you're probably familiar with a common way to facilitate a team meeting.

    Everyone is given a pad of yellow Post-it notes and a small sheet of green sticky dots. At the start of the exercise, each person writes down a few possible topics, one per Post-it note, and sticks their Post-it notes on a wall.

    [ Get the most out of Google with InfoWorld's quick guide "25 tips and tricks for Google Drive power users." Download the PDF today! | Cut to the key news in technology trends and IT breakthroughs with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]

    In the next phase, everybody walks over to the wall and arranges the notes in clusters. Finally, people vote on which topics to discuss by putting sticky dots on the appropriate clusters. It's any effective way to discover what the team has on its collective mind and, thus, how the team's precious "together time" can be used best.

    To read this article in full or to leave a comment, please click here

    by Jon Udell at May 18, 2015 10:00 AM

    Giles Bowkett

    Underrated Synth: The Korg Wavestation

    Never buy music gear without looking it up on YouTube and Vintage Synth Explorer first (or Gearslutz, or ModularGrid). And never pay for music gear without looking up the price history on eBay for the last three months. It takes five seconds and it'll save you a lot of money.

    I recently found a Korg Wavestation SR on eBay for less than $200. Although they sometimes go for less, they usually go for more. I've had my eye out for a Wavestation for a long time, and seeing one in Richie Hawtin's live setup didn't hurt. But to be sure, I checked YouTube, where I found this demo:



    It's painfully 90s, and it sounds as if it was made on the same machine that the entire X-Files theme song was made on, but that's because it was. It's also kind of awesome, in a painfully 90s way.

    by Giles Bowkett (noreply@blogger.com) at May 18, 2015 09:24 AM

    May 17, 2015

    Lambda the Ultimate

    Draining the Swamp: Micro Virtual Machines as Solid Foundation for Language Development

    Draining the Swamp: Micro Virtual Machines as Solid Foundation for Language Development
    Kunshan Wang, Yi Lin, Stephen Blackburn, Michael Norrish, Antony Hosking
    2015

    Many of today's programming languages are broken. Poor performance, lack of features and hard-to-reason-about semantics can cost dearly in software maintenance and inefficient execution. The problem is only getting worse with programming languages proliferating and hardware becoming more complicated. An important reason for this brokenness is that much of language design is implementation-driven. The difficulties in implementation and insufficient understanding of concepts bake bad designs into the language itself. Concurrency, architectural details and garbage collection are three fundamental concerns that contribute much to the complexities of implementing managed languages. We propose the micro virtual machine, a thin abstraction designed specifically to relieve implementers of managed languages of the most fundamental implementation challenges that currently impede good design. The micro virtual machine targets abstractions over memory (garbage collection), architecture (compiler backend), and concurrency. We motivate the micro virtual machine and give an account of the design and initial experience of a concrete instance, which we call Mu, built over a two year period. Our goal is to remove an important barrier to performant and semantically sound managed language design and implementation.
    Inside you will find the specification of an LLVM-inspired virtual instruction set with a memory model (enables proper GC support) including a specification of concurrent weak-memory operations (reusing C(++)11, a debatable choice), relatively rich control-flow primitive (complete stack capture enabling coroutines or JIT-style de-optimization), and live code update.

    May 17, 2015 09:46 PM

    LoperOS

    Phuctor Broke Several RSA Keys.

    (5/20 Update: This.)

    (5/18 Update: Tired of the contemptible media disinformation and faux-reporting on this subject? For some fresh air, see Mircea’s article, ‘On how the factored 4096 RSA keys story was handled, and what it means to you.’)

    Phuctor, “The RSA Supercollider,” is a long-term collaborative project of yours truly and Mircea Popescu.

    I am pleased to announce that we have now broken a 4096-bit RSA key, as well as its factor-sharing counterpart (yet to be determined, but won’t wait for long!)

    At five minutes prior to the time of this writing, another pair of keys has also been broken.  See Mircea’s site for updates.

    Readers who wish to learn more about this project are invited to join Mircea, myself, and many other fine folks on Freenode in IRC channel #bitcoin-assets. Click here for a WWW-based gateway. Politely privmessage an “up please” to one of the regulars to get speaking rights.


    Edits, Corrections:
    1 ) Threads on Reddit, Hacker News. (5/18: If you care to read these, do it while they’re still up.)
    2 ) Selected hate mail. Will update this section if any more contenders for this list should appear.
    3 ) May 17 ~16:10 EST: Aaand we got another! A GNU developer, like the first. Which makes for six phuctorable keys, three of which are presently known to me.
    4 ) Before joining the chorus of ‘Holy shit, they broke RSA!’ or ‘This is false advertising, they didn’t really do anything!’ imbeciles, please consider reading the (one whole page!) description of what Phuctor actually does.
    5 ) If you are in the service of the enemy, and think that you can somehow prevent or retard the search for weak (weak for whatever reason! I don’t weaken them, only search…) fielded RSA keys, think again. The data set is public in its entirety, and the experiment can be replicated by a schoolboy with minimal sweat. Go ahead and remove the diddled keys from public servers, if you like. We have copies.
    6 ) This is addressed to the same fine folks as #5. Your efforts to bury the story in FUD and hastily-concocted disinformation are riotously funny. Please carry on.
    7 ) Consider getting your tech news from journalists who can spell. (Seriously, ‘Phunctor’ ?!)
    8 ) (5/18) We found a number of moduli, including several pairs which share a large composite factor.  Stay tuned.
    9 ) Folks who believe that ‘anyone can insert anything into SKS‘ are invited to replace my key there with their own.
    10 ) (5/19) As of today, there are 10 broken moduli.

    by Stanislav at May 17, 2015 05:44 PM

    Dave Winer

    Apple Watch liveblog notes

    I got my Apple Watch last week, and I pretty much love it.

    I started taking notes on my exploration on my liveblog, which was designed for cumulative projects like this one. I wanted to be sure readers of Scripting News know about this.

    http://liveblog.co/users/davewiner/2015/05/13/appleWatchNotes.html

    Your comments and suggestions are welcome.

    May 17, 2015 01:53 PM

    Something doesn't smell right about the rush to "deprecate" HTTP

    Google and Mozilla and others want force all non-HTTPS sites to become HTTPS.

    And while the name HTTPS sounds a lot like HTTP, it's actually a lot more complex and fraught with problems. If what they want to do ever happens, much of the independent web will disappear.

    1. First, the problem as I understand it, is that some ISPs are gathering data about the content flowing through their routers, inserting ads and cookies and otherwise modifying content. I agree of course that this is a bad thing.

    2. Going to HTTPS does not get rid of all possible ways of snooping and modifying content. A toolbar, for example, hooking in after the content is decrypted, could change the content. Google tried to do this at one point in the evolution of the web. And even if you couldn't do it with a toolbar, Google and Mozilla both own popular browsers. They could modify content any time they want. HTTPS won't protect us against their snooping and interference. Why are we supposed to trust them more than an ISP? I don't actually trust them that much, btw.

    3. Key point: If you care about whether ISPs modify your content, you can move to HTTPS on your own. You don't need Mozilla or Google to force you to do it.

    4. It also depends on how much you care. Sure in a perfect world I'd want to stop all of it on all my content, but in that perfect world I would have infinite time to do all the work to convert all my websites. I don't have infinite time, and neither do you. I try to pick my battles more carefully. You can waste a lot of time doing something because it seems the right thing to do and end up accomplishing nothing.

    5. What I care about is that sufficiently motivated people will be able to find my archive in the future. I don't think the odds are actually very good, for a lot of reasons. This is just the newest.

    6. Given that a vast amount of content likely won't move, Google and Mozilla are contemplating far more vandalism to the web than any of the ISPs they're trying to short-circuit.

    7. Aren't there other less draconian methods to try first? How about making it illegal where it is not and working with government to enforce the laws? How about developing competition that doesn't do it, so everyone has a choice? That's the way Google is changing how ISPs work in the US. Why not elsewhere? How about developing a kind of encryption that does not require websites to do anything? I don't know if it's possible, but I haven't heard any discussion of that.

    8. Couldn't you use a VPN to tunnel through the nasty ISPs?

    9. This is why we need to overthrow the tech industry as a governing body. It's run by people who shoot first and ask questions later. This is an awful way to be having this discussion, after the decision is made, without any recourse? This is the best argument for taking this power away from the plutocrats in tech.

    May 17, 2015 01:45 PM

    May 15, 2015

    Tim Ferriss

    TF-StitcherButton

    500-358492-894__1Our conversation took place in a barrel sauna like this.

    “It’s [about] getting closer to the source and not being distracted by any nonsense…”
    – Rick Rubin

    Rick Rubin has been called “the most important [music] producer of the last 20 years” by MTV.

    Rick is also revered as something of a Zen master, and he is as deep as he is soft-spoken. He rarely grants interviews, and one condition of doing this one was the setting: his hyper-heated barrel sauna at home.

    In this episode, we delve into how Rick helps artists (e.g. Jay Z, Shakira, Johnny Cash, etc.) produce their best work. Not only that, we also discuss Rick’s step-by-step experience losing 135+ pounds. He describes underwater weightlifting stories, training with Laird Hamilton, testing different diets, and much more.

    Rick’s resume includes everyone from Johnny Cash to Jay Z. His metal artists include groups like Black Sabbath, Slayer, System of a Down, Metallica, Rage Against the Machine, and Linkin Park. He’s worked with pop artists like Shakira, Adele, Sheryl Crow, Lana Del Rey, and Lady Gaga. He’s also been credited with helping to popularize hip hop with artists like LL Cool J, The Beastie Boys, Eminem, Jay Z, and Kanye West.  And that’s just a small sample.

    This conversation teaches a cohesive lesson in breaking down complex skills with deep and subtle problem solving.

    The sauna caused the microphones to burn our hands and us to nearly pass out. DON’T TRY THIS AT HOME, folks! I think it adds a hilarious element to the whole thing, but it’s not without risks.

    [Last but not least, if you haven’t seen my new TV show, which is #1 on iTunes as I write this, please check out The Tim Ferriss Experiment! There are 13 episodes, including ones with surfer Laird Hamilton and “top 10 drummer of all-time” Stewart Copeland.]

    Enjoy!

    TF-ItunesButtonTF-StitcherButton

    Interested in learning more about world-class musicians? — Check out my interview with Amanda Palmer who left her record label and raised more than $2 million via crowd funding. (stream episode below or right-click here to download):

    Also, don’t miss Justin Boreta of The Glitch Mob, one of the biggest electronic groups on the planet. In my conversation with Justin, we play their never-before-heard draft versions of their songs and then explore what it takes for Justin to move that draft through 300+ versions to a final version which will knock your socks off (stream below or right-click here to download):


    This episode is sponsored by OnnitI have used Onnit products for years. If you look in my kitchen or in my garage you will find Alpha BRAIN, chewable melatonin (for resetting my clock while traveling), kettlebells, maces, battle ropes, and steel clubs. It sounds like a torture chamber, and it basically is. A torture chamber for self-improvement! Ah, the lovely pain. To see a list of my favorite pills, potions, and heavy tools, click here.

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Give it a test run…

    QUESTION(S) OF THE DAY: Rick Rubin cites “heart work” as critical for creatives. What is the balance of heart work and head work in your creation process? 50/50? 70/30? How did you realize what works best for you? Please let me know in the comments.

    Scroll below for links and show notes…

    Selected Links from the Episode

    Show Notes

    • The story of how Rick Rubin lost 135-145 pounds [7:50]
    • Sleep Tools: A process for rebuilding your circadian rhythm for the first time [10:50]
    • What does Rick Rubin “do”? [22:45]
    • Transitioning into a career of record producing [23:35]
    • On letting music be discovered vs. manufactured [24:30]
    • What gets in the way of artists producing their best work [26:05]
    • Recommendations for contemporary music [30:55]
    • How Rick Rubin learned that music was something he could do as a career [34:00]
    • Hip-hop to heavy metal and how to approach music with appreciation [38:05]
    • Working with artists in different genres: LL Cool J to Slayer [40:15]
    • Meditation and managing disruption [42:40]
    • Who comes to mind when Rubin thinks of the word “successful” [46:50]
    • Lessons learned from time spent with Don Wildman [49:45]
    • Most gifted books and favorite documentaries [51:35]
    • Managing the experience of overwhelm [54:30]
    • About Rick Rubin’s cameo for 99 Problems and Jay Z’s creative process [56:50]
    • On being introduced to the sauna/ice-bath combination [1:00:10]
    • Underwater weight training and lessons from Laird Hamilton [1:02:15]
    • Other exercises: Hyperbaric oxygen and the Wim Hof method  [1:08:35]
    • How Rubin uses small tasks to help others [1:10:05]
    • Advice for his 20-year old and 30-year old self [1:13:10]

    People Mentioned

    by Ian Robinson at May 15, 2015 04:11 PM

    Giles Bowkett

    Strong Parameters Are A Weak Schema

    Ruby on Rails went off the rails a long time ago.



    I don't work with Rails today. But, like so many other developers, I kept working with Rails for many years after the Merb merge. Because I loved Ruby, and because the Rails developer experience remains a thing of beauty, even today.

    I stuck around for Rails 4, and one of the changes it made was silly.
    Rails has always had a nice way of sanitizing user input coming from ubiquitous forms. Up until Rails 3, the solution was to list accessible fields right in your models. Then Rails 4 came along and introduced a different solution - strong_parameters, allowing you to take a greater control over the sanitizing process.
    As is often the case with Rails, the real problem here is that the core team failed to recognize a classic problem of computer science, after underestimating the importance of API-centric web development, and perceiving the problem purely in terms of showing a web page to a user.

    What Rails Was Thinking


    Before I get into that, I just want to summarize the problem from the Rails perspective: you've got input coming in from users, who are filling out web forms. They might be up to mischief, and they might use your web form to cause trouble. So you have to secure your web forms.

    The classic Rails solution for securing a web form: attr_accessible. Since models are the only way Rails puts anything into a database, you can recast "securing a web form" as validating an object. It makes perfect sense to say that code which secures an object's validity belongs in that object. So far, so good.

    attr_accessible was a white-listing mechanism which allowed you to specify which model attributes could be mass-assigned. The default for updating or creating an object in Rails, update_attributes, would allow a user to update any aspect of a model, including (for example) their User.id or their authorization privileges.

    But this whitelisting was disabled by default. You had to kick it into gear by calling attr_accessible at least once, in your model. People forgot to do this, including people at GitHub, a very high-profile company with great developers, which got very visibly hacked as a result. People responded by writing initializers:

    ActiveRecord::Base.update_attributes(nil)

    (Obviously, a better way to do that would be to wrap it in a method called enable_whitelist or something, but that's a moot issue now.)

    People also responded by writing plugins, and in Rails 4, one of these plugins moved into Rails core.

    So this is what changed:
    • attr_accessible had an inverse, attr_protected, which allowed you to use a blacklist instead of a whitelist. strong_parameters only permits a whitelist.
    • The whitelisting default changed from off to on.
    • The code moved from the model to the controller.
    David Heinemeier-Hansson wrote up the official rationale. I've added commas for clarity:
    The whole point of the controller is to control the flow between user and application, including authentication, authorization, and, as part of that, access control. We should never have put mass-assignment protection into the model, and many people stopped doing so long ago ...

    An Alternative Approach


    Let's look at this from a different perspective now.

    Say you're building a web app with Node.js, and you want to support an API as well as a web site. We can even imagine that your mobile app powers much more of your user base, and your web traffic, than your actual web site does. So you need to protect against malicious actors exploiting your web forms, as web apps always have. But you also need to protect against malicious actors exploiting your API traffic.

    At this point, it's very easy to disagree with Mr. Hansson's claim that "we should never have put mass-assignment protection into the model." Both the "protect against malicious actors" problems here are very nearly identical. You might have different controllers for your API and your web site, and putting mass-assignment protection into those controllers could mean implementing the same code twice. Centralizing that code in the relevant models might make more sense.

    Rails solves this by quasi-centralizing the strong_parameters in a private method, typically at the bottom of the controller file. Here's the example from the official announcement:

    But you could also just use JSON Schema. All your web traffic's probably using JSON anyway, all your code's in JavaScript already, and if you write up a schema, you can just stipulate that all incoming data matches a particular format before it gets anywhere near your application code. You can put all that code in one place, just as you could with models, but you move the process of filtering incoming input right up into the process of receiving input in the first place. So when you do receive invalid input, your process wastes less resources on it.

    (This is kind of like what Rails did, except you can put it in the server, which in Rails terms would be more like putting it in a Rack middleware than in a controller.)

    The funny thing is, writing a schema is basically what Rails developers do already, with strong_parameters. They just write their schemas in Ruby, instead of JSON.

    Here's a less cluttered example:

    Note especially the very schema-like language in this line:

    params.require(:email).permit(:first_name, :last_name, :shoe_size)

    All you're doing here is permitting some attributes and requiring others. That's a schema. That's literally what a schema is. But, of course, it lacks some of the features that a standard like JSON Schema includes. For instance, specifying the type of an attribute, so mischevious Web gremlins can't fuck up your shit by telling you that the number of widgets they want to purchase is `drop table users`. (Rails has other protections in place for that, of course, but the point is that this is a feature any schema format should provide.)

    Rails developers are writing half-assed schemas in Ruby. If/when they choose to farm out parts of their system to microservices written in other languages, they'll have to re-write these schemas in other languages. For instance, they might at that point choose to use a standard, like JSON Schema. But if you're building with the standard from the start, you only have to define that schema once, using one format.

    In fact, Rails developers typically re-write their schemas whether they refactor to microservices or not. Many Rails developers prefer to handle API output using active_model_serializers, which gives you a completely different Ruby-based schema format for your JSON output.

    Here's an example from the README:

    This code says "when you build the output JSON, serialize the name and body attributes, include post_id, and add some hypermedia-style URLs as well." It infers a lot from the database, and it's nicer to read than JSON Schema. But you can't infer a lot from a database without some tight coupling, and this syntax loses some of its appeal when you put it side-by-side with your other implicit Ruby schema format, and you have to remember random tiny distinctions between the two. It's kind of absurd to write the same schema two or three different times, especially when you consider that Ruby JSON parsing is so easy that your JSON Schema objects can be pure Ruby too if you want.

    strong_parameters really only makes sense if you haven't noticed basic things about the Web, like the fact that HTTP has a type system built in.

    by Giles Bowkett (noreply@blogger.com) at May 15, 2015 01:05 PM

    May 14, 2015

    Lambda the Ultimate

    Eve: the development diary of a programming environment aimed at non-programmers

    In spring 2012 Chris Granger successfully completed a Kickstarter fundraising and got $300K (instead of the requested $200K) to work on a live-feedback IDE inspired by Bret Victor "Inventing on principle" talk. The IDE project was called Light Table. It initially supported Clojure (the team's favourite language) only, but eventually added support for Javascript and Python. In January 2014, Light Table was open sourced, and in October 2014 the Light Table development team announced that they decided to create a new language, Eve, that would be a better fit for their vision of programming experience.

    There is little public about Eve so far, no precise design documents, but the development team has a public monthly Development Diary that I found fairly interesting. It displays an interesting form of research culture, with in particular recurrent reference to academic works that are coming from outside the programming-language-research community: database queries, Datalog evaluation, distributed systems, version-control systems. This diary might be a good opportunity to have a look at the internals of a language design process (or really programming environment design) that is neither academic nor really industrial in nature. It sounds more representative (I hope!) of the well-educated parts of startup culture.

    Eve is a functional-relational language. Every input to an Eve program is stored in one of a few insert-only tables. The program itself consists of a series of views written in a relational query language. Some of these views represent internal state. Others represent IO that needs to be performed. Either way there is no hidden or forgotten state - the contents of these views can always be calculated from the input tables.

    Eve is designed for live programming. As the user makes changes, the compiler is constantly re-compiling code and incrementally updating the views. The compiler is designed to be resilient and will compile and run as much of the code as possible in the face of errors. The structural editor restricts partially edited code to small sections, rather than rendering entire files unparseable. The pointer-free relational data model and the timeless views make it feasible to incrementally compute the state of the program, rather than starting from scratch on each edit.

    The public/target for the language is described as "non-programmers", but in fact it looks like their control group has some previous experience of Excel. (I would guess that experimenting with children with no experience of programming at all, including no Excel work, could have resulted in very different results.)

    Posts so far, by Jamie Brandon:

    Some random quotes.

    Retrospective:

    Excited, we presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked, nor could they produce any useful programs themselves. The sticking points were lexical scope and data structures. Every single person we talked to just wanted to put data in an Excel-like grid and drag direct references. Abstraction via symbol binding was not an intuitive or well-liked idea.

    [...]

    Our main data-structure was now a tree of tables. Rather than one big top-level function, we switched to a pipeline of functions. Each function pulled data out of the global store using a datalog query, ran some computation and wrote data back. Having less nesting reduced the impact of lexical scope and cursor passing. Using datalog allowed normalising the data store, avoiding all the issues that came from hierarchical models.

    At this point we realised we weren't building a functional language anymore. Most of the programs were just datalog queries on normalised tables with a little scalar computation in the middle. We were familiar with Bloom and realised that it fit our needs much better than the functional pidgin we had built so far - no lexical scoping, no data-structures, no explicit ordering. In late March we began work on a Bloom interpreter.

    October:

    Where most languages express state as a series of changes ('when I click this button add 1 to the counter'), Eve is built around views over input logs ('the value of the counter is the number of button clicks in the log'). Thinking in terms of views makes the current language simple and powerful. It removes the need for explicit control flow, since views can be calculated in any order that is consistent with the dependency graph, and allows arbitrary composition of data without requiring the cooperation of the component that owns that data.

    Whenever we have tried to introduce explicit change we immediately run into problems with ordering and composing those changes and we lose the ability to directly explain the state of the program without reference to data that no longer exists.

    [...]

    In a traditional imperative language, [context] is provided by access to dynamic scoping (or global variables - the poor mans dynamic scope) or by function parameters. In purely functional languages it can only be provided by function parameters, which is a problem when a deeply buried function wants to access some high up data and it has to be manually threaded through the entire callstack.

    December:

    Eve processes can now spawn subprocesses and inject code into them. Together with the new communication API this allowed much of the IDE architecture to be lifted into Eve. When running in the browser only the UI manager lives on the main thread - the editor, the compiler and the user's program all live in separate web-workers. The editor uses the process API to spawn both the compiler and the user's program and then subscribes to the views it needs for the debugging interface. Both the editor and the user's program send graphics data to the UI manager and receiving UI events in return.

    May 14, 2015 12:27 PM

    Fog Creek

    How to Find, Hire, and Retain Developers – Interview with Cal Evans

    .little {font-size: 75%}
    How to Find, Hire, and Retain Developers – Interview with Cal Evans

    Looking for audio only? Listen on

    We’ve interviewed Cal Evans, author of ‘Culture of Respect’, and we discuss how to find, hire, and retain Developers. He gives tips on where to find great developers, how to write job ads which appeal to them and how best to interview them. We also discuss ways to build a great team culture that can help startups and growing businesses compete with the big guys for talent.

    Hear more about such topics from Cal over on his blog and check out our video guide to hiring developers .

    Content and Timings

    • Introduction (0:00)
    • Developer Management (0:35)
    • Finding Developers (2:38)
    • Developer Job Ads (4:30)
    • Interviewing Developers (6:18)
    • Creating a Culture of Respect (11:03)
    • Common Developer Hiring Mistakes (14:59)
    • Recommended Resources (17:29)

    Transcript

    Introduction

    Derrick:
    Cal Evens is a technical manager of training at Zen, a PHP expert and community leader. He’s experienced in building and managing development teams, he’s the author of a number of books including: Going Pro, Signaling PHP and most recently, Culture of Respect: how to find, hire and retain developers. Cal, thank you so much for taking the time to join us today, do you have a bit to say about yourself?

    Cal:
    Pleased to be here, honored to be invited to participate.

    Quite honestly, if you can spell PHP, I can probably get you a job coding PHP

    Developer Management

    Derrick:
    Culture of Respect focuses on hiring and retaining developers. Why do you think people need to think about hiring and managing developers differently than those in other roles?

    Cal:
    I’m always careful to preface my talks about hiring and managing developers by saying I’ve never managed anything else. I don’t know, it could be that accountants are exactly the same but what I know are developers so that’s what I talk about. I’ve been a developer now long enough to have seen companies go from being companies that use software and occasionally developer their own, to being software companies that also do something else. Most companies these days have an in-house development team that does something, whether you’re building controllers for John Deere tractors or you’re building websites for Amazon, software is so integrated in what we do that most companies have an in house development team. Most companies these days, their in-house development team is actually what drives the company, builds the products that the company sells or makes it possible for the companies to sell.

    While I’m never an advocate for setting developers up on a pedestal and saying we need to treat them like demi gods, I do think you have to respect the fact that you have to treat them differently. You cannot just say, we have a cookie cutter, this is how we treat people. Developers have different needs. Immediately, if I start a job and they hand me a laptop that has been used by three other people and I have to figure out how to make things work, then that’s a smell test that doesn’t pass. Companies have to understand that you’ve got to invest in good tools for developers. Right now it’s a seller’s market for developers. Quite honestly, if you can spell PHP, I can probably get you a job coding PHP. I get people writing me saying we’ll train them, just give me someone with the aptitude to learn how to program. It’s a great time.

    Finding Developers

    Derrick:
    Let’s start with finding developers. What have you found to be the most effective way to find developers to hire?

    Cal:
    I’m going to talk mostly about the PHP community because that’s what I’m most familiar with but most of these should work in just about any developer community you’re working in. The first thing is get involved in your local community. That means start attending your local PHP groups on a regular basis. Go 5 or 6 months to build your relationships before you start doing any real recruiting. Even then, once you start, don’t just walk in and say, I’m here, I’m collecting resumes. Be the sponsor. Buy the pizza and the beer and the soda for the group a couple of times. That’s the first thing, get involved in your local community. The second step, and this is very important, it’s equally important, repeat the first step as necessary. Your local community is where you’re going to find your best resources. I’m a big fan of remote developers, but we’re not talking about that right now. We’re just talking about trying to find local developers. Your local community is going to be the number one.

    Once you have integrated yourself into the local community, then start looking for, in the PHP community, we have regional conferences that have come up in the past 4 or 5 years. Once you have gotten your name in regional, then you go to national conferences and you sponsor, or you just go and attend and hang out with people. Then you start moving towards the international conferences like ZendCon and Dutch PHP, these conferences, and those are great places to find developers, but at that point you’ve got to be of the mindset that you don’t have to have them sitting in a chair in a cube that you can see. You’re going to have to start doing remote before the nationals and internationals are really going to pay off for you.

    Developer Job Ads

    Derrick:
    What are some tips for writing great job ads seeking developers?

    Cal:
    Number one, I cannot stress this enough, put a salary or salary range on the job ad. You’re not limiting yourself, and you’re going to help developers pre-screen. You’re not giving away any secrets because I guarantee you, if you’ve already got developers, they’re talking to their buddies, we know how much you’re paying. If you tell us, then we can help pre-screen. Help me understand if I can afford to take the job. The second thing, if I see Photoshop on a developer ad, that’s a red flag immediately. What it tells me is you don’t understand what you want, so you’re just throwing everything out there. I advise developers, anytime they’re looking at job ads, serious developer positions, not front end developers, but mid range and back end developers, if they see Photoshop on it, walk away. It doesn’t matter who the company is, walk away. The company doesn’t understand what they’re trying to hire for. Somebody said, we’ve got a billet open, I need a PHP developer. Every now and again I need photoshop, I need front end work, so go ahead and put that on there too. That’s not what they’re looking for.

    Then what I like to call no bullshit ads. What I want to know is can I afford to take the job, am I qualified for the job, how much does the job pay? That’s the important stuff. If you nail those, then you have a good chance of finding the developer that you’re actually looking for and not have to wade through the 150 resumes you’re going to get if you put up a kitchen sink ad or a bullshit ad or something like that. I’ve been the manager that had to wade through those. I tell you this from experience because I’ve made all of these mistakes before.

    Hiring remote developers means that you can get the absolute best developer… not just the ones that are willing to live in your city

    Interviewing Developers

    Derrick:
    You’ve been critical of code testing in dev hiring, why is that?

    Cal:
    First of all, I am to the point in my career where I have a LinkedIn profile that if you printed out in a PDF, it would be 5 or 7 pages. I have 10 or 12 GitHub repos out there that show what my code is. If you as a developer manager are not qualified to read through my GitHub Repo and look at the code that I’m writing and say is this good code, and if you’re not qualified to look at my LinkedIn profile and see that I show a progression of responsibilities, then I question whether you’re qualified to manage me in the first place. So many intricate things to being a developer that if you’ve not done it, you’ve got no framework. Setting timelines and deadlines, stuff like that. If you’ve never done development, then setting deadlines is real easy. By here, by this date, but if you’ve done development then you know it’s not nearly that easy.

    Derrick:
    So what steps should people take in hiring the right developers?

    Cal:
    The number one thing that I look for is competency. If you’re not competent then you’re going to be a hindrance to the team. When I’m hiring on a team, keeping the team cohesion is very important. Once I determine competency, then we start looking at cultural fit. These days, you have to be very careful when you say cultural fit, because everybody says you’re only looking for white guys that graduated from your college. No, cultural fit does not mean that you look like me, it does not mean that you think like me. What cultural fit means it that I’ve got a team that is currently working together and you’ve got to be able to play a part on that team, and you’ve got to be able to disagree with these people, and not be a hindrance to the team. Building that team culture is so important, and keeping the team culture together, and I’ve seen great teams make a bad hiring decision and totally destroy the culture of the team, and the momentum of the team. Just because they got one person who dragged the whole team down.

    I get the entire team that the person’s going to be working on in one room and I let the team ask questions until everybody is out of all the questions. I don’t care if you’re junior, senior, architect or whatever, you’re going to get to ask any question you want of this person as long as it’s a legal question. Once they finish that, then we can move on. I never ask questions in these interviews. The team always does it. My job is to sit back and see how the team interacts with this person and how this person interacts with the team. If I see a lot of friction, I’m thinking this might not be a good fit. It doesn’t automatically disqualify them but it means I’m going to have to do a little more interviews first.

    The final thing, once I have determined competency, once I know it’s a good cultural fit, can I afford them? I am very odd in this. I do not negotiate salaries. I ask the person what do you need. I expect that person to be honest with me and tell me the number they need. The two questions I ask at that point is are we within reason, because if I’ve got a junior developer saying I need $100,000, that’s not reasonable. I’m still not going to negotiate with them but they’ve given me their answer. If they’re reasonable then the next question is can I afford them. If it fits within my budget and it’s a reasonable price and they have passed the team interview, the team has voted on them and said yes we want them, then I say okay. I don’t come back with a counter offer. I don’t negotiate this at all, because my feeling is a developer, if they’re being honest with me is going to tell me what they need to be happy with this. I don’t mind side projects but I don’t want people to have to do side projects to make ends meet. Quite honestly, if they’re not being honest with me on their salary needs, I’m probably not going to want them on my team to begin with because they’re not being honest with me, period.

    The one final point about the team voting is it has to be a unanimous vote. I’ve actually had to walk away from candidates because I had one person say I don’t think this person is going to fit well on my team, and so we said I’m sorry it’s not going to work, because the team is the one that’s going to have to work with them. I’m just going to have to manage them, that’s the easy part. The team has to work with them on a day to day basis. If that team is not sold on the fact that this person is the person that they want on their team, I’d rather just walk away and find another candidate.

    Creating a Culture of Respect

    Derrick:
    What can start ups and small companies do to compete in hiring the best talent? When you have big players offering free lunches and large salaries, etc?

    Cal:
    Free lunches, that’s crap. That’s not a benefit, that’s a perk. I understand the mentality of free lunches and dry cleaning and all of this. Those exist so the company can keep the developer’s butt in their seat longer, and they exist for no other reason. It’s just a way to keep that developer on campus, focused on the job, for as long as possible. If a small company builds a culture of respect, they respect the developer, they understand that their job is a portion of their life, their job is not their life, then you can attract better developers than companies that have free lunches, dry cleaning, a Kegerator, you name it, Foosball tables, whatever.

    My favorite example of this is in Nashville, we have Dave Ramsey, and they have a wonderful development team. Dave Ramsey’s team does not have a Kegerator. People work there because at 5 O’Clock, you’ve basically got to justify why you’re still there, because they understand that this is part of your life, it is not your life. It’s working for them because, they’re a Ruby shop, they’ve got a 6 month hiring process. It takes 6 months just to be hired by them, and yet they still have a list of candidates waiting to go through the process. They need Ruby developers right now. They’re constantly advertising for new, but they won’t compromise their team just to put a butt in a seat. They’ve got to get the right fit, and that is the focus of basically the second half of the book, of Culture of Respect. Helping managers to understand that developers have a life and their life is not building their particular project. If you understand that, then you really won’t have a problem finding developers.

    Derrick:
    So you’ve hired a great team, what are some specific things that people can do to engage developers and keep them around?

    Cal:
    I practice what’s called Servant Leadership. It was not unusual for me, when I was running teams, to first thing in the morning, brew up a huge pot of coffee and walk around to each of my developers around 9 am and refresh their coffee. Not walk by, pour a cup of coffee, and talk to them for 15 minutes, because then you get into a drive-by meeting, and you’ve interrupted them, and you’ve killed productivity. I would just refresh their coffee. I knew what everyone took, cream, sugar, made sure I had it. It was just my way of saying my job is to hire good people and get out of the way to make sure they have everything they need. My job is to serve them and also be what I call the poop shield. Anything, any poop that comes in from above, my job is to keep it off my team. If a manager needs a meeting with somebody on my team, I’ll go. I will sit in that meeting and if it actually needs a developer, I will call that developer and say I need you to come down here.

    I’ve had so many, and I learned this very early on, so many meeting requests for developers are just status meetings that they need the whole team, all the stakeholders in there, and the developer really doesn’t need to be in there. We’re just going over the project stuff. I’ll go to those meetings, I’ll take notes, and I’ll email the developer and they can read them later. If you don’t actually need a developer, then you’re costing me money by requiring a developer to sit in that meeting. That’s basically my theory, hire good people, get the hell out of the way.

    They have lives, and the main point of their lives is not to build you the next Uber for penguins

    Common Developer Hiring Mistakes

    Derrick:
    Are there any common mistakes that you see people making when hiring developers?

    Cal:
    Yes, the most common mistake I see people making is not considering remote developers. I’ve been programming for 35 years. I’ve spent more time remote than I have on site. As a developer, I can’t get work done if people can walk by and stop me and talk to me, or constant interruptions of the telephone. If I’m remote, I can turn off my phone, I can turn off my email, I can shut down twitter, and I can focus and I can get the work done. Most people don’t understand this. Hiring remote developers is much more than going out to weworkremote.com and finding someone that will do it and say boom, we’ll hire you.

    You have to have a remote developer program in place before you hire your first one. You have to understand that it’s going to be more work for you, the manager, to manage that remote person, because if you don’t hear from them, you have to reach out to them. As developers, we have this tendency, if we don’t have any interruptions, we will go heads down, get in the zone. I have actually started a project at 11 am and looked up one day and it was 11 pm that night, and I’m like, this is so cool, I got so much work done. Oh my god, it’s 11 pm at night. You lose track of time, but that’s great for developers.

    As a manager, if I’m not hearing from my developer, I don’t have to hear every 15 minutes, but I need to know that they are actually working and not playing on their Xbox. There’s a balance there, and it is more work for the manager. I get these emails all the time, ‘we’ve got a great opportunity and we’re looking for the best developer we can find’. I write them back. Great, are you willing to hire remote? ‘No’. Then you’re really not looking to hire the best, you’re looking for the most convenient, let’s be honest about it.

    Hiring remote developers means that you can get the absolute best developer that is available to you, not just the ones that are willing to live in your city. If I can get anything across to people it’s figure out how to work with remotes. One of the other things I say that really pisses people off. I tell companies, if your managers can’t handle managing remote developers, get better managers. That’s a whole lot cheaper than trying to find developers in your local area.

    Recommended Resources

    Derrick:
    What are some resources that you can recommend to those interested in learning more about dev hiring and management?

    Cal:
    There’s only been a couple of things that have really impacted me. Of course the very first one is Mythical Man-Month. You really have to understand how the timing works in building software. I believe that everybody, if you’re a manager of software development, then you need to read Mythical Man-Month, and it needs to be an annual thing. You need to keep reading it once a year until you really understand it and you can start applying it without thinking about it. Of course, Peopleware, it’s another one of our ancient tomes in software management. It’s a great one. Another one, and you’ve interviewed this person on your dev.life blog, is Paul Jones, for a talk that he does called ‘All You Jokers’.

    Software management teams like to go and say we need this built in this time frame, without any concept of what this time frame is actually going to take. It falls on developers to actually hit this time frame. That’s how we end up with the 120 hour work weeks and giving up our lives for a company that’s not going to give us anything more than a salary and possibly some stock options. It isn’t rocket science, this is basic human nature. Treat developers with respect, understand that they have lives, and the main point of their lives is not to build you the next Uber for penguins. You don’t have to put them on a pedestal but they aren’t galley slaves either. You hire good people, you treat them with respect, you give them the tools that they need and let them do their job. That is the secret to a happy, productive, and awesome development team.

    Derrick:
    Thank you so much for joining us today.

    Cal:
    Thank you for having me on.

    by Gareth Wilson at May 14, 2015 11:37 AM

    May 13, 2015

    Dave Winer

    How to have a future

    The journalism world is having a fit of depression today as they learn that their something they've actually known for years: their distribution system is owned by the tech industry.

    There is a solution. Start rebuilding your distribution system around the Internet. Instead of broadcasting to an audience, feed a community back to itself. Be distributors. Understand that you are not making the news. Your job always has been distribution.

    It's all about your rolodex

    1. Gather all the rolodexes in your organization and merge them into a database.

    2. Be sure you have a field in your database called "Feed" and in that field save the address of your source's RSS or Atom feed.

    3. Make a river out of those feeds. Start watching that river. Tell your sources about the river, give them the address. About five minutes after that you will be jumping up and down with excitement.

    4. Make it your home page.

    That's it. You've now created a future. Live in it, and learn from it, and evolve accordingly. There are no parachutes, no single well-defined path all news orgs will go down. You have to make it up as you go.

    However, until you get your river going, you will still be in the print era. Any effort you make there is wasted, it's not how news works today or in the future. We live in an era where sources have direct access to people who want the news. The sources are learning how to use that power. You have to find new relevance.

    You can use River4

    River4 is an open source aggregator written in JavaScript that does all that you need to get started. I wrote it, so you know it's good.

    One more thing

    If you're a journalism educator, please make sure every new journalist you graduate has the ability to run a server, install blogging and river software. People should not be scared of this technology. It's not hard, and is more immediately valuable than learning to "code" -- it should be a prerequisite.

    May 13, 2015 04:50 PM

    Mark Bernstein

    Why I Adore The TLS

    From Rupert Brooke, “Heaven.”

    But somewhere, beyond Space and Time.

    Is wetter water, slimier slime!

    And there (they trust) there swimmeth One

    Who swam ere rivers were begun,

    Immense, of fishy form and mind,

    Squamous, omnipotent, and kind;

    And under that Almighty Fin,

    The littlest fish may enter in.

    May 13, 2015 02:40 PM

    Dave Winer

    Facebook's Instant Articles

    A few items related to Facebook's Instant Articles announcement that came in the middle of the night.

    1. I was briefed on this project last summer.

    2. It got me interested in the Facebook API.

    3. People who use Facebook want this. How do I know? When I post full text of stories on FB they read it and comment. When I post a link to my blog post, they still comment, but very often without having read the piece. As a writer I can only take so much of this!

    4. The place to put this functionality is in the CMS or blogging tools. If I were FB, I would have gone to the toolmakers first. Made sure there was broad support. Why do they care so much about the big brands? Maybe there's something strategic about this. Do the big brands really move first, fast, with confidence and innovation? Or are they driven by fear of missing out? Which motivation creates better user experience? (In my experience love is where creativity comes from, not fear.)

    5. I was told last summer that they were building on RSS. Of course that's a good thing, if true. It means that the content could flow not just to Facebook, but anywhere that's prepared to receive it. This creates many interesting options. In this, Facebook is being a good corporate citizen and Friend to the Open Web (with the qualification that I don't know for sure if it is true).

    6. I have asked for access to the tech now that it's out, but got rejected!

    7. I hope they change their mind.

    8. Bloggers matter, imho as much as any professional reporter. I want parity for bloggers. In this way they are not being a friend of the open web.

    9. The NYT, National Geographic, Buzzfeed, et al, are right to publish their content to Facebook in full. It's one of the big places where people who read news congregate. But they should also quickly develop new channels that are not dependent on the tech industry.

    10. Journalism pundits will re-litigate the michegas over The Algorithm. The time to debate that was when it was new, five years ago. It's done now. The next thing is whether or not the news industry invests in its own future, or lets the tech industry continue to own it. The Algorithm wouldn't have mattered if journalism had done its job. I guess that's where my frustration comes from reading the hot angry frustrated powerless pieces by Jay Rosen, Zeynep Tufekci and Emily Bell. Where were you when this was news? And why are you missing the current issue? Why are you always five years late? Yes I was ringing the bells about this then. Now it's time to finally compete with Facebook and Twitter. It might already be too late, but it might not be.

    May 13, 2015 10:53 AM

    Ian Bicking

    A Product Journal: Community Participation

    I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

    Generally at Mozilla we want to engage and activate our community to further what we do. Because all our work is open source, and we default to open on our planning, we have a lot of potential to include people in our work. But removing barriers to participation doesn’t make participation happen.

    A couple reasons it’s particularly challenging:

    1. Volunteers and employees work at different paces. Employees can devote more time, and can have pressures to meet deadlines so that sometimes the work just needs to get done. So everything is going fast and a volunteer can have a hard time keeping up. Until the project is cancelled and then wham, the employees are all gone.

    2. Employees become acclimated to whatever processes are asked of them, because whether they like it or not that’s the expectation that comes with their paycheck. Sometimes employees put up with stupid shit as a result. And sometimes volunteers aren’t willing to make investments to their process even when it’s the smart thing to do, ‘cause who knows how long you’ll stick around?

    3. Employee work has to satisfy organizational goals. The organization can try to keep these aligned with mission goals, and keep the mission aligned with the community, but when push comes to shove the organization’s goals – including the goals that come from the executive team – are going to take priority for employees.

    4. Volunteers are unlikely to be devoted to Mozilla’s success. Instead they have their own goals that may intersect with Mozilla’s. This overlap may only occur on one project.  And while that’s serendipitous, limited overlap means a limit on the relationships those volunteers can build, and it’s the relationships that are most likely to retain and reward participation.

    I have a theory that agency is one of the most important attractors to open source participation. Mozilla, because of its size and because it has a corporate structure, does not offer a lot of personal agency. Though in return it does offer some potential of leverage.

    I am not sure what to do with respect to participation in PageShot. If I open things up more, will anyone care? What would people care about? Maybe people would care about building a product. Maybe the building blocks would be more interesting. We have an IRC channel, but we also meet regularly over video, which I think has been important for us to assimilate the concept and goals of the project. Are there other people who would care to show up?

    I’m also somewhat conflicted about trying to bring people in. Where will PageShot end up? The project could be cancelled. It’s open source, sure, but is it interesting as open source if it’s a deadend addon with no backing site? Our design is focused on making something broadly appealing such that it could be included in the browser – and if things go well, the addon will be part of the browser itself. If that happens (and I hope it will!) even my own agency with respect to the project will be at threat. That’s what it means to get organizational support.

    If the project was devolved into a set of libraries, it would be easier to contribute to, and easier for volunteers to find value in their participation. Each piece could be improved on its own, and can live on even if the product that inspired the library does not continue. People who use those libraries will maintain agency, because they can remix those libraries however they want, include them in whatever product of their own conception that they have. The problem: I don’t care about the libraries! And I don’t want this to be a technology demonstration, I want it to be a product demonstration, and libraries shift the focus to the wrong part.

    Despite these challenges, I don’t want to give up on the potential of participation. I just doubt would look like normal open source participation. I’ve expanded our participation section, including an invitation to our standup meetings. But mostly I need to know if anyone cares, and if you do: what do you care about and what do you want from your participation?

    by Ian Bicking at May 13, 2015 05:00 AM

    May 12, 2015

    Dave Winer

    Why I moved off Heroku

    I really appreciate the service that Heroku runs. It was a very easy way for me to get started in Node.js, and also very affordable! I kept marveling at what a great deal it was, gushed publicly about it, and paid them the highest honor, I developed my software around their architecture, so it would be really easy to deploy my stuff on Heroku.

    My basic idea is that back-ends for software are very small things. They just move data out of the app, which runs in the browser on the user's desktop, to a storage place, and back out later. That's all the server has to do.

    I designed it so that each app has its own server. That way if one of my apps got really popular, it wouldn't interfere with the others. This is ideal for developers, to have scaling be a totally fluid thing. That's why you want to chop the pieces as small as you can. Rather than try to host ten apps on a server, give each app their own server, no matter how small and insignificant. It's a design that can only work for a system like Heroku. It was really a breakthrough.

    But, they changed their pricing so as to really discourage this architecture. It's possible they weren't even aware how their change would affect us. I didn't hide the design, I wrote lots of posts about it. I emailed with people there. I even met with their CEO on a trip to California to talk about how I saw their service and to learn how they were planning to evolve it. I kept emailing them asking if they were sure this is the deal and thanking them for their generosity.

    But once they changed, I had to change. It no longer made sense to have lots of individual servers, one for each app. With the new economics. I'd have to bundle them up, the old way, where one server is running N apps. And if one gets successful, there's a bunch of manual work to set things up so it gets more resources without slowing the other apps down. Scaling is no longer a matter of sliding a slider on a browser interface. I wish it were.

    Anyway it's up to them to decide how to price their service. And it was up to me to migrate when they changed their pricing. It was a pretty hellacious weekend here, lots of stress, but it's not bad. It's kind of like a basketball player has to get really intense to make it through the playoffs. This was a very high wire balancing act. But it was a good thing to do, now I have a much better understanding of what I've done. I've moved code I wrote when I was a total newcomer to Node.js. It wasn't a horrible experience!

    And now I'm back on solid ground (knock wood, praise Murphy) I look forward to getting back to the stuff I really love, making new idea processing software that networks people in incredible new ways!

    PS: A little more perspective in a post on my liveblog.

    May 12, 2015 05:54 PM

    May 11, 2015

    Dave Winer

    Hello Fargo users

    This is a quick heads-up, there were major changes in the servers over the weekend. But if all went well, you should see no changes in the performance of Fargo.

    Basically, I moved the back-end, Fargo Publisher, from Heroku to a server in Amazon's cloud. This is a lot like the move that Berkman made a few years back when they hoisted their building on Mass Ave and moved it a few blocks away, and re-planted it. It's as if all the scholars in the offices just went home for the weekend and came back to find their offices in a new location. Hopefully all the electric is properly hooked up, and the Internet, the bathrooms. Business as usual, they say. We hope.

    Knock wood, praise Murphy, I am not a lawyer.

    Dave

    PS: There will be a new version of Fargo Publisher, shortly, if everything works. Haaha.

    May 11, 2015 12:52 PM

    Lambda the Ultimate

    FLOPS 2016, promoting cross-fertilization across the whole declarative programming and theory and practice

    LtU generally is not appropriate venue for posting call-for-papers, but there have been exceptions, if the CFP has an exceptionally wide appeal. Hopefully FLOPS 2016 might qualify.
    http://www.info.kochi-tech.ac.jp/FLOPS2016/

    FLOPS has been established to promote cooperation between logic and functional programmers, hence the name. This year we have taken the name exceptionally seriously, to cover the whole extent of declarative programming, which also includes program transformation, re-writing, and extracting programs from proofs of their correctness. There is another strong emphasis: on cross-fertilization among people developing theory, writing tools and language systems using that theory, and the users of these tools. We specifically ask the authors to make their papers understandable by the wide audience of declarative programmers and researchers.

    As you can see from the Program Committee list, the members have done first-rate theoretic work, and are also known for their languages, tools and libraries. PC will appreciate the good practical work. Incidentally, there is a special category, ``System Descriptions'' that FLOPS has always been known for. We really want to have more submissions in that category.

    One can see even on LtU that there is some rift between theoreticians and practitioners: Sean McDermid messages come to mind. He does have many good points. We really hope that FLOPS will help repair this rift.

    May 11, 2015 07:16 AM

    May 10, 2015

    Mark Bernstein

    “If We Procure Not To Ourselves More Woe”

    The theme of this dinner was borrowed from Paradise Lost. This week, my car nearly gave out, my hearing aid nearly gave out, and now my iPhone won’t charge: it was time for a low pressure meal. The straightforward recipe for a low-pressure meal is to get a holiday joint and roast it, but that seemed to dishonor all the expenses just incurred in order to delay even great expenses. So let it be a challenge.

    • “Gin” juniper Grissini ❧ Gougeres ❧ Hard Cider on the porch
    • Braised fennel, absinthe butter, salmon roe ❧ more cider
    • Homemade agnolotti stuffed with sweet potato and bacon, in fennel broth ❧ White Bordeaux
    • Duck breast, smoked over alder and tea ❧ Vaqueyras
    • Chicken legs braised in hard cider ❧ Tempranillo
    • Salad
    • Cake

    They work got off on an instructive foot as I carefully weighed my pasta eggs sans shells to get the flour to three significant figures, and then added 3:1 flour when everyone knows pasta requires 3:2. So I had precisely twice as much flour as I ought, and naturally this worked not well, or at all. Much mystery ensued, followed inevitably by a double batch of pasta and more fresh fettuccine and strozzapreti than we really need.

    Thanks to the pasta production, I never did figure out great names for the courses. But we’ve got the apple thing going in the appetizers and the chicken legs, the lcorice-tinged fennel in the first course (“Black it stood as night, Fierce as ten furies, terrible as hell, And shook a dreadful dart.”), and of course it’s bathed in seas of fire. The agnolotti are allegedly papal miters, they’re also filled with something orange. The duck breast is smoked,

    May 10, 2015 08:29 PM

    Tim Ferriss

    The_Tim_Ferriss_Experiment__Gambling___Trailer___Tim_Ferriss_-_YouTube

    The_Tim_Ferriss_Experiment__Gambling___Trailer___Tim_Ferriss_-_YouTube

    In this post, I’ll show you how Phil Gordon trained me in 5 days to have a fighting chance against pro poker players. Here’s the video teaser.

    Before we filmed the experience for The Tim Ferriss Experiment (currently the #1 TV Season on iTunes), I had never played a hand of poker.

    Phil’s crash course purposefully did not cover all the bases. It couldn’t. We didn’t have the time.

    Instead, his program (and this post) will show how a gambling idiot (me) can magnify strengths and cover weaknesses to an absurd degree…at least for a few hours in order to win real cash.

    Let’s be clear: I am not a good poker player, and perhaps you aren’t either. But that doesn’t mean you can’t win.

    If you understand a few principles and follow them religiously, Lady Luck (and strategic aggression) might smile upon you. Especially if you learn how to leverage “short-stack strategy” or “heads-up play,” both of which I’ll explain.

    This post has three parts:

    – My video explanation – This is the actual video I sent to TV post-production. I sent similar videos for all 13 episodes (parkour, the dating game, building a business, etc.) right after we finished each week. This is nuts and bolts of how Phil helped me pull off miracles.

    – My real notes from my notebook – These are PDFs of the notes I explain in the aforementioned video. For a novice or intermediate, they are only really useful once you’ve watched the video.

    – Phil’s one-page cheatsheet – ‘Nuff said.

    – The full TV episode (preview and links)

    Let’s get started on the how-to…

    The Video Explanation – The Real Nuts and Bolts

    I mention “VO” a few times, which stands for “voice over.” To see more of the notebook text, you can expand to full screen.

    My Poker Notes (Plus Some “Escape and Evasion” Notes)

    How to Play Poker – The Tim Ferriss Experiment by tferriss

    Phil’s Cheatsheet

    Poker Cheatsheet – From Pro Phil Gordon by tferriss

    The TV Episode

    Here’s the full episode (and 12 others) — check it out! If you found any of the above interesting, I think you’ll love it.

    by Tim Ferriss at May 10, 2015 07:10 AM

    May 09, 2015

    Lambda the Ultimate

    Pycket: A Tracing JIT For a Functional Language

    Pycket: A Tracing JIT For a Functional Language
    Spenser Bauman, Carl Friedrich Bolz, Robert Hirschfeld, Vasily Krilichev, Tobias Pape, Jeremy Siek, and Sam Tobin-Hochstadt
    2015

    We present Pycket, a high-performance tracing JIT compiler for Racket. Pycket supports a wide variety of the sophisticated features in Racket such as contracts, continuations, classes, structures, dynamic binding, and more. On average, over a standard suite of benchmarks, Pycket outperforms existing compilers, both Racket’s JIT and other highly-optimizing Scheme compilers. Further, Pycket provides much better performance for proxies than existing systems, dramatically reducing the overhead of contracts and gradual typing. We validate this claim with performance evaluation on multiple existing benchmark suites.

    The Pycket implementation is of independent interest as an application of the RPython meta-tracing framework (originally created for PyPy), which automatically generates tracing JIT compilers from interpreters. Prior work on meta-tracing focuses on bytecode interpreters, whereas Pycket is a high-level interpreter based on the CEK abstract machine and operates directly on abstract syntax trees. Pycket supports proper tail calls and first-class continuations. In the setting of a functional language, where recursion and higher-order functions are more prevalent than explicit loops, the most significant performance challenge for a tracing JIT is identifying which control flows constitute a loop -- we discuss two strategies for identifying loops and measure their impact.

    May 09, 2015 05:53 PM

    The Unison Programming Platform

    Unison - a next-generation programming platform, by Paul Chiusano:

    • Programs are edited in a (browser-based) semantic editor which guarantees programs are well-formed and typecheck by construction
    • The codebase is a purely functional data structure
    • The program is a UI, and UI interaction is programming
    • Persistent data sources must be accessible via a high-level, typed API

    An interesting project mentioned in a comment a few weeks ago, it now has its own website and a more descriptive abstract overview explaining it's core premises.

    Previous posts on Paul's blog are also of interest, and some feature videos demonstrating some aspects of Unison.

    May 09, 2015 12:31 PM

    Decyphering Glyph

    Separate your Fakes and your Inspectors

    When you are writing unit tests, you will commonly need to write duplicate implementations of your dependencies to test against systems which do external communication or otherwise manipulate state that you can’t inspect. In other words, test fakes. However, a “test fake” is just one half of the component that you’re building: you’re also generally building a test inspector.

    As an example, let’s consider the case of this record-writing interface that we may need to interact with.

    1
    2
    3
    4
    5
    6
    class RecordWriter(object):
        def write_record(self, record):
            "..."
    
        def close(self):
            "..."
    

    This is a pretty simple interface; it can write out a record, and it can be closed.

    Faking it out is similarly easy:

    1
    2
    3
    4
    5
    class FakeRecordWriter(object):
        def write_record(self, record):
            pass
        def close(self):
            pass
    

    But this fake record writer isn’t very useful. It’s a simple stub; if our application writes any interesting records out, we won’t know about it. If it closes the record writer, we won’t know.

    The conventional way to correct this problem, of course, is to start tracking some state, so we can assert about it:

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    class FakeRecordWriter(object):
        def __init__(self):
            self.records = []
            self.closed = False
    
        def write_record(self, record):
            if self.closed:
                raise IOError("cannot write; writer is closed")
            self.records.append(record)
    
        def close(self):
            if self.closed:
                raise IOError("cannot close; writer is closed")
            self.closed = True
    

    This is a very common pattern in test code. However, it’s an antipattern.

    We have exposed 2 additional, apparently public attributes to application code: .records and .closed. Our original RecordWriter interface didn’t have either of those. Since these attributes are public, someone working on the application code could easily, inadvertently access them. Although it’s unlikely that an application author would think that they could read records from a record writer by accessing .records, it’s plausible that they might add a check of .closed before calling .close(), to make sure they won’t get an exception. Such a mistake might happen because their IDE auto-suggested the completion, for example.

    The resolution for this antipattern is to have a separate “fake” object, exposing only the public attributes that are also on the object being faked, and an “inspector” object, which exposes only the functionality useful to the test.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    class WriterState(object):
        def __init__(self):
            self.records = []
            self.closed = False
    
        def raise_if_closed(self):
            if self.closed:
                raise ValueError("already closed")
    
    
    class _FakeRecordWriter(object):
        def __init__(self, writer_state):
            self._state = writer_state
    
        def write_record(self, record):
            self._state.raise_if_closed()
            self._state.records.append(record)
    
        def close(self):
            self._state.raise_if_closed()
            self._state.closed = True
    
    
    def create_fake_writer():
        state = WriterState()
        return state, _FakeRecordWriter(state)
    

    In this refactored example, we now have a top-level entry point of create_fake_writer, which always creates a pair of WriterState and thing-which-is-like-a-RecordWriter. The type of _FakeRecordWriter can now be private, because it’s no longer interesting on its own; it exposes nothing beyond the methods it’s trying to fake.

    Whenever you’re writing test fakes, consider writing them like this, to ensure that you can hand application code the application-facing half of your fake, and test code the test-facing half of the fake, and not get them mixed up.

    by Glyph at May 09, 2015 06:52 AM

    May 08, 2015

    Alarming Development

    Flux is good enough

    The reaction to my latest work [Two-way Dataflow] has been distinctly underwhelming. My diagnosis: I’ve solved a problem most people aren’t aware they have, and it comes at the steep price of replacing the conventional tech stack. Facebook has a cheaper solution: Flux. I have to give them credit for taking the problem seriously (unlike many of the reactive programming enthusiasts) and coming up with a pragmatic solution that just adds another layer to the stack. That’s what programmers want, not a fundamental solution in a new programming paradigm. It is obvious that we can’t keep growing the stack forever but no one wants to deal with it now. Especially computer scientists (don’t get me started).

    I think I need to shift focus to end-users and non-programmers. I’ve avoided that because I want to prove that we can dramatically simplify real large-scale programming — simplifying simple problems is not so convincing. But replacing the whole stack is just too hard to do all at once and all by myself, and only doing it on small examples is not convincing either. End-user programming could be a way to get started and get users and (especially) have collaborators. Industrial strength programming would come later, but at least I now have a sketch of how it should look. Building something real would be such a refreshing change from the last decade of thought experiments. I’m excited by the prospect of once again shipping buggy code and having irate users and getting into fights with my colleagues. That’s life.

    by Jonathan Edwards at May 08, 2015 04:48 PM

    Ian Bicking

    A Product Journal: As We May Discuss

    I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

    In a presentation The Revolution Will Be Annotated, Dan Whaley begins with a very high-minded justification for annotation: that it is essential for our existence that we act wisely, and that we can achieve that through deliberation, and that annotation is a building block for open deliberation.

    In response, let me digress wildly, and talk about elementary school.

    It is common to cite large class sizes as a problem, and small class sizes as an opportunity to improve education. But there is debate about whether class size really matters; it certainly correlates with general privilege, but does it cause improvements? At the same time I’ve become much more familiar with the Montessori philosophy of education, and one of the surprising features is a relatively large ideal classroom size, in the 30s. And why? Dr. Montessori had positive theories about age mixture, community size, the culture of the classroom, and so forth – but I’ll add what I think is a Montessori-style reason it’s okay: it’s okay to have less teachers because learning isn’t caused by teachers. Learning is ultimately an internal process, an assimilation and construction of knowledge. Your environment can aid in that process, but the cause is still internal.

    I share Dan’s enthusiasm about the importance of dialog to our collective wisdom. But I see dialog as supportive of personal growth, not of collective wisdom – our collective wisdom will increase as we individually grow.

    Dan cites one problem with rationalism: we are good at constructing rational arguments to support what we already believed. The annotation remedy is to suppose that what we conveniently leave out of our arguments can be applied later by a diverse set of participants. Annotation makes it harder to make use of fallacies, harder to make use of limited narratives, because the annotator can add them back in.

    I will cite another problem with rationalism: even a good rational argument is not good at convincing anyone of anything. A good rational argument is like teaching arithmetic by telling someone that 39301+9402=48703. Maybe even writing out the steps used to make that calculation. You can lay that in front of someone, you can lay a hundred similar examples in front of someone, and they will not learn arithmetic. If the person is disinterested they can just trust you – though then it hardly matters if you were right – but if they are interested I believe that the process of construction is necessary. You have to solve your own math problems to learn math.

    Annotation is interesting because it gives another avenue for people to publish their beliefs and enter into dialog. But a global overlay of annotation is not a particularly appealing medium. It’s not a place to come to understanding, to practice the construction of ideas. And I think our collective wisdom depends on an incredible volume of discussion, not just on an increased quality, because you can’t get large scale individual growth without large scale discussion.

    I see two features in the typical annotation system: one feature is the ability to talk about other things, with high fidelity. URLs have been a great start to being able to talk about things on the web, but they have some limits. The second feature is the ability to view these annotations implicitly. The second feature is the one I’ve seldom found interesting as a reader, and disagree with as a goal. Viewing annotations as a universal overlay of commentary asks too much of the annotations, provides too little to me as the reader, and I think is an attempt to pursue a kind of rational universal truth that I find little value in. It’s a sense that documents are there to teach us, and annotations make those documents even better teachers.

    PageShot takes a different approach: it gives anyone the ability to talk about anything on the web, but each time you do that you create a new resource, your discussion lives at your document. You can write your commentary for a specific audience, and then give it to that audience, without having your intended audience confused with the original author’s intended audience. You can throw away what you have to say. The person who clicks on your link did it to see what you said, they aren’t some passerby. You can say implicitly through highlighting, here is what I thought was interesting. But PageShot applies no universality to what you say, it is a tool only of dialog. This makes PageShot more modest, but intentionally so.

    by Ian Bicking at May 08, 2015 05:00 AM

    May 07, 2015

    Giles Bowkett

    My Skepticism Re: Uber Continues Unabated

    Previously: What If Uber's Just A Terrible Business?

    There's a City Paper article online where the author worked as an Uber driver and talks about how it works, especially the practical, can-I-make-a-living economics of it.

    This web site is so awful that you apparently have to open up Developer Tools to read it, and execute this line of code in the console:

    function contentRefresh(){}

    But the content's great. Spoiler alert: drivers can't make money. Uber's pricing strategy matches my fear that they're using venture capital to buy off entire cities by flooding them with amazing deals which seem like they can't last forever — because they can't — while building up the economic equivalent of a mountain of legacy code which collapses into an utter shitpile the day somebody buys the company. Only in this case, the acquirer's probably a whole bunch of people buying stock.

    But what really kicked my skepticism into high gear was this excerpt:
    TechCrunch broke the news that Uber was building a huge robotics lab in Pittsburgh, partnering with Carnegie Mellon University to "kickstart autonomous taxi fleet development," according to a company source.

    Travis Kalanick, the CEO and founder of Uber, said at a conference last year that he'd replace human Uber drivers with a fleet of self-driving cars in a second...

    You can get a glimpse of his vision in a fascinating paper from Columbia University, which did several case studies on what a future with driverless cars would look like — apparently, like Uber crossed with Minority Report. And this could be coming as soon as 2020, according to both Tesla and Google, both of which are also heavily invested in the race to be a player in this huge future market.

    In this world, the paper projects, fewer and fewer people own private cars, because it doesn’t make financial sense. Cars run on electricty, and most are much smaller, designed to carry only one or two people. The auto industry experiences a temporary boom, but then demand drops off a cliff. By around 2040, driverless cars are a majority on American roads. The number of cars drops by more than 90%, as do fuel consumption and emissions. Car accidents and traffic are nearly nonexistent.
    So, a little context.

    First, I'm a programmer, and like any programmer, I know most people's code sucks.



    Second, in the late 1990s, the whole sales pitch for why young people should build the Web in the first place was that it would democratize media, eliminate the shallow hegemony of things like NBC and CNN, and replace it with in-depth, nuanced debate, because everything would be better once it revolved around the written word.

    This is what we got instead.


    Take the "which hormone-crazed moose are you?" quiz!

    Maybe you don't remember the 1990s. Maybe you weren't there. Do you remember Heartbleed? Because that was last year. Do you remember the day the whole Internet discovered that none of our security had ever been working, and how relieved we all were when the entire rest of the world failed to notice, and civilization didn't collapse?

    One mistake that stupid in one technology underpinning robot cars, and the entire world will notice.

    I would have bought "by around 2040, driverless cars are a majority on American roads." It's entirely possible. But "car accidents and traffic are nearly nonexistent" makes the whole thing stink of bullshit so much that nothing can redeem those paragraphs now.

    Say you want to replace trucks with robots. This is a worthy goal, and in fact I know of a cool startup headed in a similar direction. There are probably many. But keep in mind that long-haul cargo trucks are often operated by poorly-educated individuals driving under the influence of crystal meth. Your startup does not need to achieve a "nearly nonexistent" accident rate to succeed. It only needs to outperform poorly-educated individuals who are driving under the influence of crystal meth.

    Also, cars are only sized for people because people make up the majority of vehicle cargo, and the entirety of vehicle operators. But if your vehicle's operator size is measured in millimeters, because it's a piece of silicon, then you suddenly only need to consider the size of your cargo. So, we're supposed to believe that traffic will become less of a problem, in a situation where there now exist compelling financial incentives to build extremely large vehicles, extremely tiny vehicles, and vehicles of every size in between?


    This is a car.


    These are also cars.

    And keep in mind you can now use automated vehicles to transport anything.



    And that cars can now have legs.



    So this is what we're supposed to believe:

    We're going to add an incredible level of variety to the sizes, shapes, and purposes of vehicles on the road, and in the skies. We're going to pilot them with software, not people, because software's cheaper and faster.

    But this new, incredible diversity in size and purpose will not affect traffic patterns negatively. The software will not have any bugs, and if the software ever somehow does have a bug, those bugs will never be catastrophic, even though the software could be piloting any of an incredible range of possible vehicles, at any of an incredible range of possible speeds, while carrying any of an incredible range of possible cargo types — including human beings, nuclear waste, or angry bees.

    Are you fucking kidding me?


    The angry bees thing really happened. Fourteen million bees were released in a truck crash; the driver was stung countless times.

    Here's a more likely scenario: these fuckers are going to crash a drone full of angry bees into a robot semi transporting nuclear waste, and then the whole thing is going to spill onto a fleet of robot Ubers, smashing the cars, killing everyone inside, and then turning the corpses into goddamn bee zombies with nuclear bee powers.

    DON'T SAY I DIDN'T WARN YOU.

    It's entirely possible the authors of this white paper were fools, rather than liars, but what they're saying is certainly false, one way or the other. There do not exist sufficient financial incentives for a perfect accident rate. An accident rate that keeps lawsuits from eating up profits is the most reasonable thing to expect. The higher those profits are, the more accidents they can subsidize. And that's what we can expect from the people whose code works.

    But most people's code doesn't work. Most people's code almost makes sense, but not quite. So most software in very widespread use is doing things which almost make sense, but not quite, at scale.

    Anyway, this report wasn't sponsored by Uber. But here's the billionth thing associated with Uber which is making my bullshit detector scream bloody murder. That's all I'm saying.

    By the way, I love robots. I went to RobotsConf and piloted a drone with Node.js, and I loved every second of it. But I'm pretty sure I also crashed it into somebody's head at least twice.

    by Giles Bowkett (noreply@blogger.com) at May 07, 2015 10:46 AM

    Fog Creek

    Remote Working Tips – Interview with Wade Foster

    .little {font-size: 75%}
    Remote Working Tips – Interview with Wade Foster

    Looking for audio only? Listen on

    We’ve interviewed Wade Foster, CEO of Zapier and author of ‘The Ultimate Guide to Remote Work‘. We discuss his experience with remote working and running a distributed company. We go into the tools, processes and hiring practices necessary to succeed with remote working, as well as some of the drawbacks and challenges that come along with it.

    Content and Timings

    • Introduction (0:00)
    • About Wade and Zapier (0:20)
    • Remote Working at Zapier (1:17)
    • Successful Remote Working Processes (4:07)
    • Tools for Remote Working (5:25)
    • Characteristics of the Best Remote Employees (6:47)
    • The Drawbacks of Remote Working (11:27)
    • Recommended Resources (14:00)

    Transcript

    Introduction

    Derrick:
    Wade Foster is Co-founder & CEO at Zapier, a YC alum company founded in 2011. Zapier is a distributed company, with 25 employees spread around the world. Wade wrote the book, ‘The Ultimate Guide to Remote Work’, in which he provides advice from his experience with remote working. Welcome Wade, why don’t you share a bit about yourself?

    About Wade and Zapier

    Wade:
    I’m one of the three co-founders and the CEO here at Zapier. We started it about a little over three years ago now really just to help hook up apps for small businesses. There are so many apps out there today. We hook into over 400 and we’re not even close to having support for all of them. It allows non-programmers, non-technical folks to just do simple automation between apps we normally use.

    For example, if you use a tool like Trello which listeners are probably aware of, you can do things like create a recurring Trello card in there or you can email in cards to create Trello cards. Or you could say when someone fills out this Wufoo form, it should automatically create a card in Trello. It just hooks up into all these different systems, so that you can make Trello work a lot nicer with things.

    It doesn’t just work with Trello. It works with all the tools that you’re probably familiar with like Dropbox, Gmail, MailChimp, SalesForce, the list goes on. That’s kind of the gist of Zapier.

    Remote Working at Zapier

    Derrick:
    Zapier has always been a distributed company from the outset. Why is this, and how has it worked for you whilst you’ve grown?

    Wade:
    So, when we started, Brian, Mike and I all lived in the same place. We were in Columbia, Missouri, but we still had day jobs. Mike was still in school. Zapier started as a side project. It just doesn’t make sense when you have limited time with a side project, it doesn’t make sense like, “Let’s all wait until we’re all hanging out in the same room looking right at each other to work on this project.” We said the thing that just makes sense is when we have time, let’s try and make as much progress as we could. We’d do that at nights from our homes, from coffee shops, from the library. Sometimes we’d meet together and work on something or at each other’s houses or whatever.

    That was definitely the exception to the rule. It was like that for the first nine months or so. Then we got into YC and we actually for the only time in Zapier’s history, the three of us worked in the same place together. After YC ended, Mike, we’d moved out to California for YC and then after it ended, Mike moved back to Missouri because his then girlfriend, now wife was in law school and he wanted to be with her. Then we hired a guy to do support in Chicago, so it was kind of like ‘hey, this just seems like the way we’re going to do things’. Really, it’s kind of like this remote, distributed asynchronous workplace was just kind of baked in from the beginning for us.

    So I think it’s definitely allowed us to hire people that we’ve worked with. In the beginning, we hired people that we worked with before. That we knew were good. They didn’t necessarily live in the same place. We were able to hire good people and there was kind of like this built in trust where we didn’t have to go recruit people from scratch who we had never worked with, we weren’t sure if it’s going to work out or not, which would have been tough for us because in California we had just moved there. We didn’t know anybody really. It felt like taking a huge chance on people.

    Early on we got to work with people that we knew were going to be great because we had already worked with them and they were great. It didn’t matter where they lived. Then as we’ve grown it’s certainly been a benefit to be able to add on. We started hiring people that we don’t know. We have a standard interview process. Things like that. It works out really great because we get to work with people who are super smart all over the world. It helps with just really kind of random silly stuff too, like our support team in spread all over the world, so we’re pretty close to having 24 hour support, which is something that very little tech teams have.

    From a DevOps perspective we have people who are around the world, so like if the site’s having issues, you don’t have to wake up at 3AM to fix it because it’s someone else’s lunchtime and they can help fix it. There’s this nice convenience when you have people when you can set your stuff up to where everyone is working all over the world and get to use the timezone diversity kind of to your advantage.

    Successful Remote Working Processes

    Derrick:
    How has working remotely impacted the processes you use to get work done?

    Wade:
    I think process is actually really important. A lot of early companies kind of think that hinders their creativity or whatever, but I think for a remote team it’s really important because and if you’re co-located you can get away with not having it because you can always just yell across the room and say, “Hey dude, this thing or whatever.”

    In a remote team, people aren’t in the same time zone, so they may not be able to have access to you right at that right time. That means you need to make sure that documentation is really, really good. From the outset you’re making sure that the documentation’s good, you’re making sure that information is available, so having public Dropbox accounts, having an internal wiki, having Slack or HipChat or something so that there’s these public logs of stuff that’s going on. Your code is well documented. All that stuff is really important because it allows people to get their jobs done in the absence of help being around right that very instant.

    That’s why I think process is really important, it really provides the groundwork for people to self-serve, do their job even if they don’t necessarily have a person there to answer a question for them. They do have information there that they can go do some research and figure out the answer themselves.

    Tools for Remote Working

    Derrick:
    What tools do you think are key to supporting remote work?

    Wade:
    So there’s a handful of tools that we use. I don’t think the actual tool is as important as the category of tool. Like you probably need one of these tools in your tool bag.

    For instance we use Slack for our group chat. You could just as easily use HipChat or Campfire or something. They’re both great as well. We use Trello for lightweight project management. We have an internal blog/Reddit style tool that we call Async that we built that we use to replace internal emails. There’s really no internal email at Zapier to speak of. Then we use GitHub for our code hosting and issue management. Then Help Scout is for support and other external email I guess that comes into Zapier. Really that’s all we use on the tools side of things.

    Occasionally we’re on Google Hangout or GoToMeeting or whatever. Not much other than that. We bake in other tools like from here to there. Certain individuals will use a different tool for something. They might use Zapier to pull it into the main tools. However we try and keep it pretty light on tools because that’s just one less thing for people. Oh, HackPad, that’s another one that we use all the time. We use that for all our internal documentation and it’s pretty slick.

    Characteristics of the Best Remote Employees

    Derrick:
    Zapier is growing quickly, what should people consider when hiring remote employees?

    Wade:
    I think probably the most important thing with remote work is that you’re able to trust these people. Even if you don’t know someone, do you feel comfortable with them enough to give them just free reign? Do you trust that if I can’t see you, I know that you’re going to be getting stuff done? What that means is that the types of people that I feel like even though I don’t know them, that I can trust them are ones that come in and they show like whether in their past projects that they’ve taken a lot of initiative. Maybe that means that they’ve done side projects or they’ve gone above and beyond current work. Somehow they’ve shown I’m not just going to do the lowest bar. I’m going to do extra stuff on the side.

    That’s the kind of person who just in the absence of I guess direction is just going to find stuff to do and find interesting problems and tackle them. I think that’s really key. The second thing is how well do they communicate via written words? Are their email correspondence with us early on in the conversation, are they being crystal clear? Do they know how to schedule a meeting in different timezones? It’s kind of a silly thing to know, but if you screw that up, that’s kind of shows that you’re not really hooked into how this sort of stuff will work.

    People who have done freelance work or contract work are also pretty good because they’ve had to work with… Set their own schedules. They’ve had to deal with clients externally. They’ve had to deliver expectations to people. There’s a lot more knowns with those types of people. Those are some things that I think are pretty important. Then of course they need to have all the other stuff that a great teammate would have, right? You want someone that’s not a jerk. You want someone that can walk a mile in somebody else’s shoes. Who’s not going to have a huge ego. That stuff that you would want whether you work remotely or not. On top of that you really want to have the good communication skills and you want them to have to have the initiative to go above and beyond and not have to wait for instructions I guess.

    One of the things I think is really key too for new teammates is that they need to have an outside social group. If you’re the type of person that’s used to your work colleagues being also your social colleagues, that’s probably not going to be… Remote work is probably not going to be a great fit for you. You want to be able to have family or friends or something else in your physical world so that when work ends, you can actually go out and socialize with a real human being from time to time. I think that’s pretty important to help mitigate, like feeling too remote or isolated from the rest of the world. You want to make sure that you’ve got that outside network that’s not tied to your job.

    Derrick:
    Company culture is key to the continued success of any company. How can you build a great working culture whilst working remotely?

    Wade:
    Tools like Slack and HipChat make it pretty easy. A lot of our, we have fun with memes and gifs and stuff inside of Slack. It takes on, you see how culture evolves inside of internet communities, like Reddits, sub-Reddits or Hacker News or some other forum that you may be a part of. You’ve seen how culture develops.

    It’s kind of similar to that in a remote team. You have to make sure to foster that a little bit. You make sure that new folks know the rules of the road about ‘hey, it’s kind of okay to be a little edgy’ or maybe we’re not a little edgy with how we do stuff inside of our Slack room or whatever. That kind of gets people to kind of know a little bit where the boundaries are without having to be too strict about it.

    Then of course we also get together in person a couple times a year. Twice a year we fly everyone out to some location and do a retreat. You get to spend time, see people face to face and you realize ‘hey, this person is the person that I work with and they’re a real human being. They exist in the real world somehow’, which is like it’s pretty important for a team when that’s not a normal occurrence.

    It’s actually pretty special too. I find it a lot more exciting to see my teammates at Zapier than when I worked in a co-located facility. It’s a more rare instance. The fact that you get to see someone. I don’t know. It’s a little more exciting. That makes the culture, I guess those face to face meetings help really I guess evolve the culture as well too.

    The Drawbacks of Remote Working

    Derrick:
    What are some of the main drawbacks you’ve experienced from working remotely?

    Wade:
    Communication is I think probably the biggest challenge. I think that’s the biggest challenge for even co-located teams. The thing that’s really tricky I guess with communication is when you’re co-located you can be a little bit lazy about it.

    You don’t have to be as explicit about who’s doing what or what’s going on because you’re sitting right next to each other, you can see what each other’s working on. Someone starts to get off track you can be like, “Hey, what is that? What’s going on there?” Or if you’ve got some issue you can just shout across the room and say, “Hey Bob, can you help me with this thing?” or whatever.

    It allows you to be a little bit lazier. With a remote team you really have to be pretty organized with how things are getting done. You have to know these are the things that people are working on. These projects, these are the most important projects that are getting done right now, so that those key tasks kind of get checked off. If you’re dealing with timezone differences, you kind of know what’s happening so that the person who’s halfway across the world when you’re sleeping, they don’t feel like they’re completely lost about what’s going on or what’s happening.

    You need to be really, really, I guess, upfront about what’s happening in your company. The way that we get away with that is just through our internal blog, with public communication, so everything is… anytime you make progress on a thing you post something to the blog saying ‘here’s what’s happening. Here’s what’s going on’. If you have a key question about something you post it to the internal blog. Make something that’s going on.

    Any time that you’ve built a new tool or built a new feature you document it inside of our internal docs so that people who come along know how to use it, know what it’s for. There’s no place in Zapier, if you were going to build a feature, if you’re going to do something, there’s no such thing as hiding it or hoarding it to yourself. That’s the worst thing you could do on a remote team. The most important thing is once you have set something up, you need to provide the right links to the tool or the feature or the process or whatever and you need to write documentation around it so that other people know how to use it or modify it or do something with that thing.

    I think that’s probably the most critical thing is getting that communication layer right and making sure that new people know that that is a huge priority. That you can’t be lazy about that. It’s like the most important thing that you could do. I think that’s certainly, that’s probably the biggest challenge with remote teams is just getting that communication layer right.

    Recommended Resources

    Derrick:
    What are some resources you can recommend for those interested in finding out more about how to successfully build a distributed company?

    Wade:
    So the book that I wrote, ‘The Ultimate Guide To Remote Work’, I think is pretty good, but in particular the very last chapter of that book has a list of some of my favorite resources that I’ve read. There’s Basecamp, it has their book. Remote 37 Signals, the Remote Book. The team at Treehouse has written dome good stuff. Fog Creek has written some good material on this. Buffer has written some good material on this. There’s lots of interviews with the Automattic team about remote work. I think there’s not a ton of companies doing this, but the ones that are are doing a pretty good job of sharing what’s working well and what’s not working well for them.

    I think that’s just really helpful to being able to see what’s worked for others. Especially others that are maybe a little bit bigger than whatever your company’s at right now because as you grow you kind of can guess what the next problems are going to be because they’ve already solved them. That’s super nice. I know for us, the Buffer team I think is exactly a year older than us. They’re just maybe like five to ten people ahead of us in hiring. It’s really nice because and they’re super transparent about everything, so it’s really nice because they ran all their stuff and we just get this nice guidebook of stuff that we should be watching out for next. We don’t use it exactly, don’t copy them exactly, but it’s just nice to know a little bit of what other companies are experiencing.

    Derrick:
    Thanks for your time today, Wade.

    Wade:
    Yeah, thanks for having me.

    by Gareth Wilson at May 07, 2015 09:03 AM

    Tim Ferriss

    TF-StitcherButton

    Noah Kagan on The Tim Ferriss Show
    Noah Kagan was #30 at Facebook, #4 at Mint.com, and is the Chief Sumo (founder) at SumoMe, which offers free tools to help grow website traffic. To keep things extra spicy, he’s become a taco connoisseur and created 4 separate products that have generated more than 7 figures.

    This podcast conversation is about all of the tools and tricks he uses to do it all.

    Noah was my co-teacher in the “Starting a Business” episode of The Tim Ferriss Experiment, which is now the #1 TV season across all of iTunes. In the episode, we help a novice entrepreneur named Cindy to develop and launch her business in a single week. See all the details here, and be sure to watch the bonus hour of behind-the-scenes footage.

    But back to the current podcast…

    Noah and I cover a ton, including his favorite tools, apps, books, routines, and more.  It ranges from apps for preventing distractions, to how he blocks out time every Tuesday for learning, to how he gained 40 pounds of (mostly) muscle in the last six months or so.

    If you loved the resource-rich business interviews with Ramit Sethi and Tracy DiNunzio, you’ll love this one.

    So, here’s the interview, chock full of tools, cursing, and sexual innuendo…

    TF-ItunesButtonTF-StitcherButton

    If you can’t see the above, here are other ways to listen:

    This podcast is brought to you by Athletic Greens (AG), my all-in-one nutritional insurance policy. It’s a whole food-derived greens powder that I’ve used since 2008 or so to cover my bases in a busy world. If I need to skip meals or eat sub-optimal food, AG allows me to worry less. For travel, I take pouches with me to prevent fatigue. For a limited time, you can try AG at 50% off! Click here.  It ain’t cheap, but I find it totally worth it.

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour BodyHere are some of the impressive results.

    QUESTION(S) OF THE DAY:  Are you afraid of doing the “coffee challenge” that Noah describes? If so, why? If not, please do it and share the results in the comments. Feel free to share any other experiences with “comfort challenges” like those in The 4-Hour Workweek.

    Scroll below for all show notes, links, resources, etc….

    Enjoy!

    Subscribe to The Tim Ferriss Show on iTunes.
    Non-iTunes RSS feed

    Links from the Episode

    SumoMe: website, Twitter, Facebook
    Noah’s blog

    Peter Thiel
    Alfred App
    Facebook Newsfeed Eradicator
    Schedule Once ($99 a year option)
    Andrew Warner
    Followup.cc
    Perch.co
    Myfitnesspal.com
    Quest protein bars
    Tuft and Needle
    My Pillow
    Parachute bedding
    Steve Pavlina
    Tucker Max
    Monthly 1K
    Darren Rowse
    Shane Snow
    Taco Deli
    Gary Halbert Letters
    Kopywriting Kourse
    Draft
    Hemingway
    The Pleasure of Finding Things Out – Richard Feynman
    Mybodytutor.com
    Coach.me
    Stickk.com
    Dietbet.com
    Withings Scale
    The Online Coach – the SHUL workout
    Pavel Tsatsouline
    Travis Brewer
    Email1k.com/tim
    RAD Roller
    Evan Williams Bourbon
    Charlie Hoehn
    Videofruit.com

    Nutribullet
    Datpiff.com
    Travis Scott
    Wale
    Promise Ring

    Router that Noah recommends

    Books Mentioned

    The Martian

    Go the F**k to Sleep

    Who — Here is Noah’s short and personal book report on Who. I have about 10 pages of notes from this book. It’s well worth purchasing (I prefer Kindle version so I can highlight and export).

    The 22 Immutable Laws of Marketing

    Essentialism

    The Ultimate Sales Machine

    Million Dollar Consulting

    The Sales Acceleration Formula

    Smartcuts

    SPIN Selling

    Ogilvy on Advertising

    Small Giants

    Surely You’re Joking Mr. Feynman!

    Starting Strength

    Practical Programming

    Show Notes

    Noah’s ad for living in Austin, TX [1:39]
    Noah’s favorite tools he’s using right now [6:26]
    Noah’s health/fitness routine [13:43]
    Noah’s mattress and bedding recommendations [17:08]
    Why Noah organizes his dollar bills in his wallet [25:14]
    What the coffee challenge is [30:54]
    The 3 most important (but undervalued) things people should spend more time learning [45:43]
    What REALLY changed the game for Noah in his writing style [47:59]
    Why Noah blocks out 2 hours every Tuesday morning just for learning [58:54]
    Noah’s tips for adding muscle [1:03:01]
    Noah’s business rules [1:17:00]
    Noah’s challenge to build your email list (prize included) [1:27:00]
    How to get a custom email address added to your Gmail [1:33:30]

    by Christine Baird at May 07, 2015 05:06 AM

    Blue Sky on Mars

    Saying No to Sales

    There it was, right in my inbox:

    If you go ahead and make those changes, we’ll come on board and send you a check for $75,000.

    75 grand was a buncha cash for GitHub back in 2010. It became pretty clear that this was going to be no ordinary sales thread I was about to deal with.


    When I first started at GitHub, I worked on GitHub Firewall Install. This was our version GitHub that you could install on your own servers. This was the product that would eventually evolve into GitHub Enterprise.

    OG GitHub Enterprise

    A month or two into my employment, we got an email in the sales queue from a prospective company with a short list of needs in our product. They made it abundantly clear that they couldn’t switch to GitHub without these points addressed. If we went ahead and built them, though, boom, easy 75k. Hell, that was more than my year’s salary. Not too shabby.

    While all of their needs combined wouldn’t take more than a day or two of development time, most of them were requests that were pretty obvious we didn’t want to add to our product. There was a real concern about bloating our app and increasing our support burden and costs.

    I was still feeling really new to the gig and was pretty nervous about this large potential contract, so I remember spending a good half hour or so responding to the email, considering my approach. I didn’t want to piss away potential future customers, even if we couldn’t help them today.

    Those are great suggestions, and we’ll keep them in mind. Or maybe, We have some interesting thoughts about solving these problems in the future. Perhaps god you’re stressing me the fuck out dude. Or no, maybe we should just go with Sorry, but that’s not feasible in our current product.

    Eventually I found a tactful way to put my thoughts into words and fired off a response.

    Not three minutes later, I received a response back:

    Cool, no problem. My boss made me ask that. We’ll have a check in the mail later today.

    That was that.


    The whole exchange is still burned into my memory five years later because it was the first surprising sales lesson I learned: don't go chasing the quick buck.

    It’s a bit of a cliché in the startup world to always focus on the product rather than what your customers think they need. Henry Ford and faster horses and all that. I knew this, and we talked about this constantly on the team, but it’s still one of those things that can blindside you if you’re not actively thinking about it.

    Money can be really tempting.

    But everything you add to your product dilutes everything else. It becomes harder to use. It becomes more expensive to support. And chasing individual features and one-off fixes can unfortunately shield you from coming up with even simpler approaches that solve this problem and seven others at the same time.

    That’s not to say you should ignore customer feedback, or ignore your sales channel, or anything of the sort. It just means you deeply consider every little product change you make. It means you only make these changes if it aligns with your goal and will make your users happier in the long-term. It means you're proactive rather than reactive.

    If you believe in your product, and you have faith that what you're building is the way forward, hold your ground and resist adding things just for the short-term gain. The long-term can kill you just as well, and by that point it may be too late to save it.

    May 07, 2015 12:00 AM

    May 06, 2015

    Dave Winer

    I would have hired Doug, but..

    Philip Greenspun wrote a post on his Harvard blog about MIT grads over 50 having a hard time finding work. In his post he cites a piece I wrote about how I would have hired Doug Engelbart, when I was running my first startup in the 80s. His piece is getting a lot of traffic. That's good. I'm glad people are thinking about this.

    My saying I would have hired Doug Engelbart in the 1980s means nothing about the job market in 2015. What I would have done in 1985 is irrelevant today. I'm not hiring. And I'm pretty sure my counterpart in 2015 doesn't feel the way I might have felt then.

    I might have hired Engelbart because his work laid the foundation for the work we were doing at Living Videotext. He felt his work wasn't finished. We could have helped him achieve his vision, and he could have helped us make our software more useful. Perhaps we could have skipped years of evolution, avoiding the blind alleys he had to back out of in his earlier work.

    Now the big wheel has turned and today I'm in the situation Engelbart was in in the 80s. Unlike Engelbart, I have re-tooled. I now work in JavaScript in the browser and on the server. I had to walk away from the codebase that I loved. I understood that the price of relevance is to give up fighting at some point and settle for a partial victory. I think I was right in the development environment I created. But right doesn't mean the world uses what you created. Maybe 20 or 30 years from now these ideas will have gained traction. I won't be programming then. I almost certainly won't even be alive.

    I turned 60 over the weekend. It's a tough birthday, or it was for me. I didn't want to have it in public, so I told Facebook not to announce it. I think younger people don't understand. I finally think I understand how they don't understand. The ones that love me say I'm really young, and I appreciate that. I think they mean my thinking is flexible, and I'm excited about the future, like a young person might be. But the clock ticks in predictable ways. My body is that of a 60 year-old. And the world treats me as one as well. Most people can't see or feel the enthusiasm an older person has. Or they don't believe. Or they don't think.

    Like Engelbart in the 80s, I feel my work is not done. I still pump out ideas executed in software at an amazing clip. I wonder why people don't wonder how I do it. The processes I use, investing in good tools and underpinnings, and paying attention to good features of other people's software, makes it easy and quick to try out new ideas. Some of them are really worth it. Look at the list of achievements on the smallpicture.com home page for an idea.

    I want to share what I know. I want people to use my products. There's not that much road in front of me to get the work done. I'm pretty sure that there will be a lot left on my plate when I finally hang em up for the last time. I guess that's a sign of a rich and productive creative life.

    PS: An earlier version of this post, on my liveblog, became the top item on Hacker News. Quite an interesting discussion ensued, with no slamming. Coooool.

    May 06, 2015 10:24 PM

    Mark Bernstein

    Guidelines

    Writers’ Guidelines for Fallen London, the stylish interactive Web Fiction from Failbetter.

    Weather: It never more than drizzles in Fallen London. There’s no wind unless Storm is up to shenanigans. The temperature doesn’t change much.

    Is it possible to read series bibles of completed series – Buffy, say, or Babylon 5? Where? It might be an interesting comparison.

    Thanks, Stacey Mason

    May 06, 2015 01:14 PM

    Giles Bowkett

    Eurorack Is Awesome

    One of the most important technological tasks in electronic music is intermachine communication. You might have a drum machine, a synthesizer to play a bass line, another synth to play a melody, and a sampler to play a loop from an old 1970s funk song. You might want all these devices to play at the same time. Or you might just want your computer to tell them which notes to play.

    MIDI is the ubiquitous protocol which most music machinery uses for communication. It stands for Musical Instrument Digital Interface, and it's a simple protocol which can only transmit very limited data. It replaced CV, which stands for Control Voltage. CV is more expressive than MIDI, but its original implementations were very unreliable and inconvenient. MIDI offered reliability, regularity, perfect timing, and rock-solid stability.

    For years, a small group of hipsters and hackers have wanted to replace MIDI with OSC, which stands for Open Sound Control, but it's never really taken off. The protocol carries more data than MIDI, uses a URL-like naming scheme, and has a number of other significant advantages, but has failed to see much acceptance, enthusiasm, or awareness. My gut feeling is that it was just too complicated.

    Meanwhile, CV's experienced an incredible renaissance. Where previous decades saw a great deal of incompatibile implementations, most CV-oriented gear today organizes around a common standard called Eurorack for voltages, machine sizes, and power consumption. Artists such as the Chemical Brothers, deadmau5, John Tejada, Orbital, Richard Devine, Nectarios, and Alessandro Cortini from Nine Inch Nails have embraced Eurorack, and Eurorack manufacturers have produced a ton of expressive, very powerful, and wildly innovative new instruments. Most Eurorack manufacturers are tiny companies — one of the best, Cwejman, is literally one person — but bigger names like Roland and Dave Smith Instruments have gotten involved in the past few months.

    I'm not entirely sure what the lesson to learn here is. CV's renaissance stems from several factors:
    • Control voltage is an intensely simple API. (Control voltage is to synths what stdin and stdout are to Unix.)
    • Electronics are more reliable to manufacture today than they were when CV was first developed.
    • Vintage synth fanatics kept CV alive.
    • Advances in DSP and ever-tinier microprocessors make it easier than ever to build tiny, sophisticated instruments.
    • Software-emulated modular synthesis systems like Reason and Reaktor introduced a new generation to modular techniques.
    • Eurorack modules interact very simply and readily, while the Eurorack market is full of quirky experiments and ideas, sold in short runs. This combines intermittent rewards with scarcity, so it's a lot like if Lego blocks were sold the way Magic: The Gathering cards are. That's inherently addictive, and it's caused the market to grow.
    Without diving into these causes in great detail, it's really hard to identify which are the most important driving forces. API simplicity looks like the best explanation, but it's also kind of a perfect storm.

    by Giles Bowkett (noreply@blogger.com) at May 06, 2015 10:57 AM

    Venture Capital Makes Us All Stupid (But So Does Moore's Law)

    Most of the stupidest shit in hacking is programmers reinventing wheels. The new wheels start out square, and eventually become round. Sometimes the process of becoming round takes a very long time. CSS is one obvious example, but you see it over and over — in GUIs, in distributed systems, in language design, and everywhere else.

    Avoiding the mistakes of the past is a very old problem with a very old solution: listen to people who have been there before. But old people are pushed out of the tech industry, where "old" means "over 30." I think there are two main reasons for this.

    First, Moore's Law pushes virtually everything to become a computer. To computerize any given thing becomes cheaper and cheaper with every passing moment, and most things become more useful with the change. But as every object becomes computerized, the demand for programmers grows and grows, and it really shows no sign of stopping for quite a while.

    It may slow or disappear altogether once computers learn to write code for themselves, but it may not. At the very minimum, the black market for illegal hacks will grow and grow and grow, irrespective of who wrote the systems being hacked, or indeed who wrote the hacks.

    For the forseeable future, because each generation is "always" larger than the one which came before it, it's going to be a truism that programming will "always" seem overrun with kids. But because people are very prone to stereotyping and overestimating the importance of successful flukes, a field overrun with young people is a great petri dish for cultivating ageism.

    And venture capital exacerbates this problem. They're gamblers. They like to think they bet on likely winners, but it's more accurate to say they bet on what they perceive as likely winners. In other words, they go for young white men from Ivy League universities, not because those individuals truly have any higher probability of success, because venture capitalists are human, and they're as susceptible to logical fallacies, stereotyping, and superstition as the rest of us.

    But they're more influential than the rest of us. So, like their sexism, their racism, and their tendency to chase shallow fads, their ageism becomes the industry's ageism.

    To be clear, they're not responsible for all of it. There are built-in factors which make ageism highly likely, if not necessarily inevitable.

    But they make it worse. They hire young people straight out of college to reinvent wheels, badly, in huge numbers.

    And keep in mind that Moore's Law is almost a force of nature, while venture capitalists are a group of people. Of the two forces that are making us stupid, one of them can be reasoned with (relatively speaking, at least).

    I don't think these trends are very likely to dissipate, but it's worth it to try and get some sense into their heads. And if you're a VC looking for an edge, I have good news: wisdom is inherently valuable, yet it has a terrible marketing problem, and will probably continue to do so for your entire lifetime.

    by Giles Bowkett (noreply@blogger.com) at May 06, 2015 09:59 AM

    Three Gripes About Time Travel In Science Fiction

    First, the grandfather paradox isn't real. All you do is get Buddhist with it. The moment is all that exists; time is just a way of tracking configuration permutations within the moment. Hopping out of one moment and into another, without travelling through all the intermediate moments, already suspends the allegedly tight coupling between time and chains of cause and effect. The grandfather paradox is for people who've never bothered to read quantum physics.

    Second, while time may not truly exist in the classical sense, air certainly does. In normal life, when we travel from moment to moment, we can move into a new physical location by pushing air out of the way. If you suddenly appear somewhere because you've travelled through time, you suddenly share space with other matter. Although you might not, which brings me to the third issue.

    If you're on a planet which is rotating about its own axis and rotating around the axis of the sun and located within a solar system which is itself moving through space at 45,000 miles per hour, then any time travel system would have to involve a lot of travel through space as well, unless its only purpose was to cause people to die horribly in the most scientifically impressive way. Because ten seconds ago, the entire planet was somewhere else. So if you push somebody into another point in time without also changing their physical position, they'll probably just be stranded in the vaccuum of space.

    Like anything else, a practical time travel system would have to solve a lot of theoretically unrelated problems in order to be even slightly useful. And most of the "oh wow man that shit is deep" that goes on around time travel stories is just not.

    by Giles Bowkett (noreply@blogger.com) at May 06, 2015 08:44 AM

    Tim Ferriss

    timterrace___Flickr_-_Photo_Sharing_

    timterrace___Flickr_-_Photo_Sharing_This happy-looking shot was taken in 1999, when I almost destroyed myself.

    In this post, I’m going to talk about suicide, and why I’m still on this planet.

    These are stories I’ve kept secret from my family, girlfriends, and closest friends for years. Recently, however, I had an experience that shook me — woke me up — and I decided that it was time to share it all.

    So, despite the shame I might feel, the fear that is making my palms sweat as I type this, allow me to get started.

    Here we go…

    A TWIST OF FATE

    “Could you please sign this for my brother? It would mean a lot to him.”

    He was a kind fan. There were perhaps a dozen people around me asking questions, and he had politely waited his turn. The ask: A simple signature.

    It was Friday night, around 7pm, and a live recording of the TWiST podcast had just ended. There was electricity in the air. Jason Calacanis, the host and interviewer, sure knows how to put on a show. He’d hyped up the crowd and kept things rolling for more than 2 hours on stage, asking me every imaginable question. The venue–Pivotal Labs’ offices in downtown SF–had been packed to capacity. Now, more than 200 people were milling about, drinking wine, or heading off for their weekends.

    A handful of attendees gathered near the mics for pics and book inscriptions.

    “Anything in particular you’d like me to say to him? To your brother?” I asked this one gent, who was immaculately dressed in a suit. His name was Silas.

    He froze for few seconds but kept eye contact. I saw his eyes flutter. There was something unusual that I couldn’t put a finger on.

    I decided to take the pressure off: “I’m sure I can come up with something. Are you cool with that?” Silas nodded.

    I wrote a few lines, added a smiley face, signed the book he’d brought, and handed it back. He thanked me and backed out of the crowd. I waived and returned to chatting with the others.

    Roughly 30 minutes later, I had to run. My girlfriend had just landed at SFO and I needed to meet her for dinner. I started walking towards the elevators.

    “Excuse me, Tim?” It was Silas. He’d been waiting for me. “Can I talk to you for a second?”

    “Sure,” I said, “but walk with me.”

    We meandered around tables and desks to the relative privacy of the elevator vestibule, and I hit the Down button. As soon as Silas started his story, I forgot about the elevator.

    He apologized for freezing earlier, for not having an answer. His younger brother–the one I signed the book for–had recently committed suicide. He was 22.

    “He looked up to you,” Silas explained, “He loved listening to you and Joe Rogan. I wanted to get your signature for him. I’m going to put this in his room.” He gestured to the book. I could see tears welling up in his eyes, and I felt my own doing the same. He continued.

    “People listen to you. Have you ever thought about talking about these things? About suicide or depression? You might be able to save someone.” Now, it was my turn to stare at him blankly. I didn’t know what to say.

    I also didn’t have an excuse. Unbeknownst to him, I had every reason to talk about suicide. I’d only skimmed the surface with a few short posts about depression.

    Some of my closest high school friends killed themselves.
    Some of my closest college friends killed themselves.
    I almost killed myself.

    “I’m so sorry for your loss,” I said to Silas. I wondered if he’d waited more than three hours just to tell me this. I suspected he had. Good for him. He had bigger balls than I. Certainly, I’d failed his brother by being such a coward in my writing. How many others had I failed? These questions swam in my mind.

    “I will write about this” I said to Silas, awkwardly patting his shoulder. I was thrown off. “I promise.”

    And with that, I got into the elevator.

    INTO THE DARKNESS

    “They tried to bury us. They didn’t know we were seeds.”
    – Mexican proverb

    There are some secrets we don’t share because they’re embarrassing.

    Like that time I met an icon by accidentally hitting on his girlfriend at a coffee shop? That’s a good one (Sorry, N!). Or the time a celebrity panelist borrowed my laptop to project a boring corporate video, and a flicker of porn popped up–a la Fight Club–in front of a crowd of 400 people? Another good example.

    But then there are dark secrets. The things we tell no one. The shadows we keep covered for fear of unraveling our lives.

    For me, 1999 was full of shadows.

    So much so that I never wanted to revisit them.

    I hadn’t talked about this traumatic period publicly until last week, first in a reddit AMA (Ask Me Anything), then in greater depth on Derek Halpern’s podcast.

    What follows is the sequence of my downward spiral.

    Reading the below, it’s incredible how trivial some of it seems in retrospect. At the time, though, it was the perfect storm.

    I include wording like “impossible situation,” which was reflective of my thinking at the time, not objective reality.

    I still vividly recall these events, but any quotes are paraphrased. Please also excuse any grammatical/tense errors, as it was hard for me to put this down. So, starting where it began…

    • It’s my senior year at Princeton. I’m slated to graduate around June of 1999. Somewhere in the first six months, several things happen in the span of a few weeks:
  • I fail to make it to final interviews for McKinsey Consulting and Trilogy Software, in addition to others. I have no idea what I’m doing wrong, and I start losing confidence after “winning” in the game of academics for so long.

  • A long-term (for a college kid, anyway) girlfriend breaks up with me shortly thereafter. Not because of the job stuff, but because I became more insecure during that period, wanted more time with her, and was massively disruptive to her final varsity sports season. What’s wrong with me?

  • I have a fateful meeting with one of my thesis advisors in the East Asian Studies department. Having read a partial draft of my work, he presents a large stack of original research in Japanese for me to incorporate. I walk out with my head spinning — how am I going to finish this thesis (which generally run 60-100 pages or more) before graduation? What am I going to do?

  • It’s important to note that at Princeton, the senior thesis is largely viewed as the pinnacle of your four-year undergrad career. That’s reflected in its grading. The thesis is often worth around 25% of your entire departmental GPA (English department example here).

    After all of the above, things continued as follows…

    • I find a rescue option! In the course of researching language learning for the thesis, I’m introduced to a wonderful PhD who works at Berlitz International. Bernie was his name. We have a late dinner one night on Witherspoon Street in Princeton. He speaks multiple languages and is a nerd, just like me. One hour turns into two, which turns into three. At the end, he says, “You know, it’s too bad you’re graduating in a few months. I have a project that would be perfect for you, but it’s starting sooner.” This could be exactly the solution I’m looking for!
  • I chat with my parents about potentially taking a year off, beginning in the middle of my senior year. This would allow me time to finish and polish the thesis, while simultaneously testing jobs in the “real world.” It seems like a huge win-win, and my parents— to their credit —are hugely supportive.

  • The Princeton powers OK the idea, and I meet with the aforementioned thesis advisor to inform him of my decision. Instead of being happy that I’m taking time to get the thesis right (what I expected), he seems furious: “So you’re just going to quit?! To cop out?! This better be the best thesis I’ve ever seen in my life.” In my stressed out state, and in the exchange that follows, I hear a series of thinly veiled threats and ultimatums… but no professor would actually do that, right? The meeting ends with a dismissive laugh and a curt “Good luck.” I’m crushed and wander out in a daze.

  • Once I’ve regained my composure, my shock turns to anger. How could a thesis advisor threaten a student with a bad grade just because they’re taking time off? I knew my thesis wouldn’t be “the best thesis” he’d ever seen, so it was practically a guarantee of a bad grade, even if I did a great job. This would be obvious to anyone, right?

  • I meet with multiple people in the Princeton administration, and the response is — simply put — “He wouldn’t do that.” I’m speechless. Am I being called a liar? Why would I lie? What was my incentive? It seemed like no one was willing to rock the boat with a senior (I think tenured) professor. I’m speechless and feel betrayed. Faculty politics matter more than I do.

  • I leave my friends behind at school and move off campus to work — I find out remotely — for Berlitz. “Remote” means I end up working at home by myself. This is a recipe for disaster. The work is rewarding, but I spend all of my non-work time — from when I wake to when I go to bed — looking at hundreds of pages of thesis notes and research spread out on my bedroom floor. It’s an uncontainable mess.

  • After 2-3 months of attempting to incorporate my advisor’s original-language Japanese research, the thesis is a disaster. Despite (or perhaps because of) staring at paper alone for 8-16 hours a day, it’s a Frankenstein’s monster of false starts, dead ends, and research that shouldn’t be there in the first place. Totally unusable. I am, without a doubt, in worse shape than when I left school.

  • My friends are graduating, celebrating, and leaving Princeton behind. I am sitting in a condo off campus, trapped in an impossible situation. My thesis work is going nowhere, and even if it turns out spectacular, I have (in my mind) a vindictive advisor who’s going to burn me. By burning me, he’ll destroy everything I’ve sacrificed for since high school: great grades in high school got me to Princeton, great grades in Princeton should get me to a dream job, etc. By burning me, he’ll make Princeton’s astronomical tuition wasted money, nothing more than a small fortune my family has pissed away. I start sleeping in until 2 or 3pm. I can’t face the piles of unfinished work surrounding me. My coping mechanism is to cover myself in sheets, minimize time awake, and hope for a miracle.

  • No miracle arrives. Then one afternoon, as I’m wandering through a Barnes and Noble with no goal in particular, I chance upon a book about suicide. Right there in front of me on a display table. Perhaps this is the “miracle”? I sit down and read the entire book, taking copious notes into a journal, including other books listed in the bibliography. For the first time in ages, I’m excited about research. In a sea of uncertainty and hopeless situations, I feel like I’ve found hope: the final solution.

  • I return to Princeton campus. This time, I go straight to Firestone Library to check out all of the suicide-related books on my to-do list. One particularly promising-sounding title is out, so I reserve it. I’ll be next in line when it comes back. I wonder what poor bastard is reading it, and if they’ll be able to return it.

  • It’s important to mention here that, by this point, I was past deciding. The decision was obvious to me. I’d somehow failed, painted myself into this ridiculous corner, wasted a fortune on a school that didn’t care about me, and what would be the point of doing otherwise? To repeat these types of mistakes forever? To be a hopeless burden to myself and my family and friends? Fuck that. The world was better off without a loser who couldn’t figure this basic shit out. What would I ever contribute? Nothing. So the decision was made, and I was in full-on planning mode.

  • In this case, I was dangerously good at planning. I had 4-6 scenarios all spec’d out, start to finish, including collaborators and covers when needed. And that’s when I got the phone call.

  • [My mom?! That wasn’t in the plan.]

  • I’d forgotten that Firestone Library now had my family home address on file, as I’d technically taken a year of absence. This meant a note was mailed to my parents, something along the lines of “Good news! The suicide book you requested is now available at the library for pick up!”

  • Oops (and thank fucking God).

  • Suddenly caught on the phone with my mom, I was unprepared. She nervously asked about the book, so I thought fast and lied: “Oh, no need to worry about that. Sorry! One of my friends goes to Rutgers and didn’t have access to Firestone, so I reserved it for him. He’s writing about depression and stuff.”

  • I was shocked out of my own delusion by a one-in-a-million accident. It was only then that I realized something: my death wasn’t just about me. It would completely destroy the lives of those I cared most about. I imagined my mom, who had no part in creating my thesis mess, suffering until her dying day, blaming herself.

  • The very next week, I decided to take the rest of my “year off” truly off (to hell with the thesis) and focus on physical and mental health. That’s how the entire “sumo” story of the 1999 Chinese Kickboxing (Sanshou) Championships came to be, if you’ve read The 4-Hour Workweek.

  • Months later, after focusing on my body instead of being trapped in my head, things were much clearer. Everything seemed more manageable. The “hopeless” situation seemed like shitty luck but nothing permanent.

  • I returned to Princeton, turned in my now-finished thesis to my still-sour advisor, got chewed up in my thesis defense, and didn’t give a fuck. It wasn’t the best thesis he’d ever read, nor the best thing I’d ever written, but I had moved on.

  • Many thanks are due to a few people who helped me regain my confidence that final semester. None of them have heard this story, but I’d like to give them credit here. Among others: My parents and family (of course), Professor Ed Zschau, Professor John McPhee, Sympoh dance troupe, and my friends at the amazing Terrace Food Club.

  • I graduated with the class of 2000, and bid goodbye to Nassau Hall. I rarely go back, as you might imagine.

  • Given the purported jump in “suicidal gestures” at Princeton and its close cousins (Harvard appears to have 2x the national average for undergrad suicides), I hope the administration is taking things seriously.  If nearly half of your student population reports feeling depressed, there might be systemic issues to fix.

    Left unfixed, you’ll have more dead kids on your hands, guaranteed.

    It’s not enough to wait for people to reach out, or to request that at-risk kids take a leave of absence “off the clock” of the university.

    Perhaps regularly reach out to the entire student body to catch people before they fall?  It could be as simple as email.

    [Sidenote: After graduating, I promised myself that I would never write anything longer than an email ever again. Pretty hilarious that I now write 500-plus-page books, eh?]

     

    OUT OF THE DARKNESS

    “Being deeply loved by someone gives you strength, while loving someone deeply gives you courage…”
    – Lao Tzu

    First, let me give a retrospective analysis of my near obliteration.  Then, I’ll give you a bunch of tools and tricks that I still use for keeping the darkness at arm’s length.

    Now, at this point, some of you might also be thinking “That’s it?! A Princeton student was at risk of getting a bad grade? Boo-fuckin’-hoo, man. Give me a break…”

    But… that’s the entire point.  It’s easy to blow things out of proportion, to get lost in the story you tell yourself, and to think that your entire life hinges on one thing you’ll barely remember 5-10 years later. That seemingly all-important thing could be a bad grade, getting into college, a relationship, a divorce, getting fired, or just a bunch of hecklers on the Internet.

    So, back to our story–why didn’t I kill myself?

    Below are the realizations that helped me (and a few friends).  They certainly won’t work for everyone suffering from depression, but my hope is that they help some of you.

    1. Call this number : 1 (800) 273-8255. I didn’t have it, and I wish I had. It’s the National Suicide Prevention Lifeline (website and live chat here). It’s available 24 hours a day, 7 days a week, in both English and Spanish.

    If you’re outside of the US, please click here for a list of international hotlines.

    Sometimes, it just takes one conversation with one rational person to stop a horrible irrational decision. If you’re considering ending your life, please reach out to them.  If you’re too embarrassed to admit that, as I was, then you can ping them “just to chat for a few minutes.” Pretend you’re killing time or testing different suicide hotlines for a directory you’re compiling. Whatever works.

    Speaking personally, I want to see the gifts you have to offer the world. And speaking from personal experience, believe me: this too shall pass, whatever it is.

    2. I realized it would destroy other people’s lives. Killing yourself can spiritually kill other people.

    Even if you’re not lucky enough, as I was, to feel loved by other people, I think this is worth meditating on.

    Your death is not perfectly isolated. It can destroy a lot, whether your family (who will blame themselves), other loved ones, or simply the law enforcement officers or coroners who have to haul your death mask-wearing carcass out of an apartment or the woods. The guaranteed outcome of suicide is NOT things improving for you (or going blank), but creating a catastrophe for others. Even if your intention is to get revenge through suicide, the damage won’t be limited to your targets.

    A friend once told me that killing yourself is like taking your pain, multiplying it 10x, and giving it to the ones who love you.  I agree with this, but there’s more.  Beyond any loved ones, you could include neighbors, innocent bystanders exposed to your death, and people — often kids — who commit “copycat suicides” when they read about your demise. This is the reality, not the cure-all fantasy, of suicide.

    If think about killing yourself, imagine yourself wearing a suicide bomber’s vest of explosives and walking into a crowd of innocents.

    That’s effectively what it is.  Even if you “feel” like no one loves you or cares about you, you are most likely loved–and most definitely lovable and worthy of love.

    3. There’s no guarantee that killing yourself improves things!

    In a tragically comic way, this was a depressing realization when I was considering blowing my head off or getting run over.  Damnation!  No guarantees.  Death and taxes, yes, but not a breezy afterlife.

    The “afterlife” could be 1,000x worse than life, even at its worst.  No one knows. I personally believe that consciousness persists after physical death, and it dawned on me that I literally had zero evidence that my death would improve things. It’s a terrible bet. At least here, in this life, we have known variables we can tweak and change. The unknown void could be Dante’s Inferno or far worse. When we just “want the pain to stop,” it’s easy to forget this. You simply don’t know what’s behind door #3.

    In our desperation, we often just don’t think it through. It’s kind of like the murder-suicide joke by one of my favorite comics, Demetri Martin:

    “Someone who commits a murder-suicide is probably somebody who isn’t thinking through the afterlife. Bam! You’re dead. Bam! I’m dead. Oh shit … this is going to be awkward forever.”

    4. Tips from friends, related to #2 above.

    For some of my friends (all high achievers, for those wondering), a “non-suicide vow” is what made all the difference. Here is one friend’s description:

    “It only mattered when I made a vow to the one person in my life I knew I would never break it to [a sibling]. It’s powerful when you do that. All of a sudden, this option that I sometimes played around in my mind, it was off the table. I would never break a vow to my brother, ever. After the vow and him accepting it, I’ve had to approach life in a different way. There is no fantasy escape hatch. I’m in it. In the end, making a vow to him is the greatest gift I could have given myself.”

    As silly as it might sound, it’s sometimes easier to focus on keeping your word, and avoiding hurting someone, than preserving your own life.

    And that’s OK. Use what works first, and you can fix the rest later. If you need to disguise a vow out of embarrassment (“How would I confess that to a friend?!”), find a struggling friend to make a mutual “non-suicide vow” with.  Make it seem like you’re only trying to protect him or her. Still too much? Make it a “mutual non-self-hurt” vow with a friend who beats themselves up.

    Make it about him or her as much as you.

    If you don’t care about yourself, make it about other people.

    Make a promise you can’t break, or at the very least realize this: killing yourself will destroy other people’s lives.

     

    PRACTICAL GREMLIN DEFENSE

    Now, let’s talk day-to-day tactics.

    The fact of the matter is this: if you’re driven, an entrepreneur, a type-A personality, or a hundred other things, mood swings are part of your genetic hardwiring.  It’s a blessing and a curse.

    Below are a number of habits and routines that help me. They might seem simplistic, but they keep me from careening too far off the tracks.  They are my defense against the abyss. They might help you find your own, or use them as a starting point.

    Most of this boxed text is from a previous post on “productivity ‘hacks’ for the neurotic, manic-depressive, and crazy (like me)“, but I’ve added a few things:

    Most “superheroes” are nothing of the sort. They’re weird, neurotic creatures who do big things DESPITE lots of self-defeating habits and self-talk.

    Here are some of my coping mechanisms for making it through the day:

    1) Wake up at least 1 hour before you have to be at a computer screen. E-mail is the mind killer.

    2) Make a cup of tea (I like pu-erh like this) and sit down with a pen/pencil and paper.

    3) Write down the 3-5 things — and no more — that are making you most anxious or uncomfortable. They’re often things that have been punted from one day’s to-do list to the next, to the next, to the next, and so on. Most important usually = most uncomfortable, with some chance of rejection or conflict.

    4) For each item, ask yourself:

    – “If this were the only thing I accomplished today, would I be satisfied with my day?”
    – “Will moving this forward make all the other to-do’s unimportant or easier to knock off later?”

    5) Look only at the items you’ve answered “yes” to for at least one of these questions.

    6) Block out at 2-3 hours to focus on ONE of them for today. Let the rest of the urgent but less important stuff slide. It will still be there tomorrow.

    7) TO BE CLEAR: Block out at 2-3 HOURS to focus on ONE of them for today. This is ONE BLOCK OF TIME. Cobbling together 10 minutes here and there to add up to 120 minutes does not work.

    8) If you get distracted or start procrastinating, don’t freak out and downward spiral; just gently come back to your ONE to-do.

    9) Physically MOVE for at least 20 minutes each day. Go for a long walk, lift weights, take a free online yoga class (YouTube), anything. Ideally, get outside. I was once asked by friend for advice on overcoming debilitating stress. The answer I repeated over and over again was: “Remember to EXERCISE daily. That is 80% of the battle.”

    10) Follow a diet that prevents wild blood sugar swings. This means avoiding grains and refined carbohydrates most of the time. I follow the slow-carb diet with one cheat day per week and have done so for 10+ years.  Paleo also works great. Don’t forget to eat plenty of fat. High protein and low fat can give you low-grade symptoms of rabbit starvation.

    11) Schedule at least one group dinner with friends per week.  Get it on the calendar no later than 5pm on Monday.  Ideal to have at least three people, but two is still great medicine.

    12) Take a minute each day to call or email someone to express gratitude of some type. Consider someone you haven’t spoken with in a long time.  It can be a one-line text or a 5-second voicemail.

    Congratulations! That’s it.

    Those are the rules I use, and they help steer the ship in the right direction.

    Routines are the only way I can feel “successful” despite my never-ending impulse to procrastinate, hit snooze, nap, and otherwise fritter away my days with bullshit. If I have 10 “important” things to do in a day, I’ll feel overwhelmed, and it’s 100% certain nothing important will get done that day. On the other hand, I can usually handle 1 must-do item and block out my lesser behaviors for 2-3 hours a day.

    And when — despite your best efforts — you feel like you’re losing at the game of life, never forget: Even the best of the best feel this way sometimes. When I’m in the pit of despair with new book projects, I recall what iconic writer Kurt Vonnegut said about his process: “When I write, I feel like an armless, legless man with a crayon in his mouth.”

    Don’t overestimate the world and underestimate yourself. You are better than you think.

    TO WRAP UP THIS LONG-ASS POST

    My “perfect storm” was nothing permanent.

    If we let the storms pass and choose to reflect, we come out better than ever. In the end, regardless of the fucked up acts of others, we have to reach within ourselves and grow. It’s our responsibility to ourselves and–just as critical–to those who love and surround us.

    You have gifts to share with the world.

    You are not alone.

    You are not flawed.

    You are human.

    And when the darkness comes, when you are fighting the demons, just remember: I’m right there fighting with you.

    The gems I’ve found were forged in the struggle. Never ever give up.

    Much love,

    Tim

    P.S. If you have tips that have helped you overcome or manage depression, please share in the comments. I would love for this post to become a growing resource for people. I will also do my best to improve it over time. Thank you.


    Additional Resources:

    If you occasionally struggle like me, these resources, videos, and articles might help you rebound. I watch the video of Nick Vujicic quite often, just as a reminder of how fortunate I am:

    The National Suicide Prevention Lifeline – 1 (800) 273-8255 (website and live chat here). It’s available 24 hours a day, 7 days a week, in both English and Spanish. Outside the US? Please click here for a list of international hotlines.

    My recent interview with Derek Halpern – The core of the conversation is about how to overcome struggle and the above suicide-related story, but it also includes business strategies and other lessons learned.  My apologies for the weird lip smacking, which is a nervous tic. I thought I’d fixed it, but these stories brought it back :)

    15-Minute Audio from Tony Robbins I asked Tony for his thoughts on suicide. He responded with a very insightful audio clip, recorded while in the air. It covers a lot, and the hilarious anecdote about the raw-foodist mom at the end alone makes it worth a listen. NOTE: Of course, NEVER stop taking anti-depressants or any medicine without medical supervision. That is not what Tony is recommending.
    https://fhww.files.wordpress.com/2015/05/tony_robbins_suicide_audio.m4a
    Listen in the player above, or download by right-clicking here and choosing “save as.”

    The Prescription for Self-Doubt? Watch This Short Video (Nick Vujicic)

    Harnessing Entrepreneurial Manic-Depression: Making the Rollercoaster Work for You

    Two Root Causes of My Recent Depression – This article is by Brad Feld, one of my favorite start-up investors and a world-class entrepreneur in his own right. It’s just more proof that you’re not alone. Even the best out there feel hopeless at times.  It can be beaten.

    Radical Acceptance by Tara Brach.  This book is not nearly as woo-woo as it might seem.  It was recommended to me by a neuroscience PhD who said it changed her life, then by another cynical friend who said the same.  It is one of the most useful books I’ve read in the last two years.  It’s easy to digest, and I suggest one short chapter before bed each night.  For those of us who beat ourselves up, it’s a godsend.

    by Tim Ferriss at May 06, 2015 07:29 AM

    May 05, 2015

    Dave Winer

    Fog Creek

    How to Hire the Smartest Developers – Video Guide

    .video { margin-right: 15px; height: 46px; }

    It’s no secret that hiring Developers is hard. Hiring great Developers is even harder. So it’s not surprising that companies are going to great lengths to attract the top talent, and competition is fierce.

    But attracting talent is only half the battle. It’s difficult to make the right hiring decisions too. Of up most importance is a hiring process that allows you to spot the best candidates amongst your applicants. To help you, we’ve created a video series that takes you through the key steps in hiring the smartest programmers.

    Covering everything from résumé screening to interviews and making the final hiring decision, these six short videos provide some helpful tips on how to hire the best engineering talent. It’s a process that has worked well for us and has contributed to us creating some great products that people love.

    Check out the full video series, or learn more about each video below:

    1. Why Hire the Smartest Programmers?

    Learn how hiring the best programmers benefits the whole team and how they can make 10x the difference.


    2. Résumé Screening

    Find out why you should look out for ‘PBECS’ in all candidates and see some good and bad résumé examples.

    3. Phone Interviews

    This video covers the key aspects of a phone interview and the kinds of questions that work well in phone interviews.

    4. Remote Code Tests

    Learn about the scenarios that work in remote code tests and what to look out for in the best candidates.

    5. In-person Interviews

    This video covers examples of good interview questions, the importance of question consistency and just how many interviews you should run.

    6. Hire or No Hire?

    When it comes to making the hiring decision, hear why we think there should be no Ifs, Buts or Maybes.

    by Gareth Wilson at May 05, 2015 09:19 AM

    May 04, 2015

    Mark Bernstein

    The Virgins

    An accomplished and skillfully-written prep school story that takes its characters seriously. The students here are not so much young as simply inexperienced: they know a lot, they have strong opinions and determined characters and they are not fools, but they haven’t done any of this before. Bruce Bennet-Jones, the unreliable and unpleasant narrator, looks on as his classmate Seung Jung wins the love of the girl Bennet-Jones cannot possess, the new girl in school, Chicagoan Aviva Rossner. Fascinating, strange, and serious.

    May 04, 2015 02:39 PM

    John Udell

    In search of the Holy Grail of audio and video editing

    In "A better way to capture team meetings," I explored Google's Hangouts on Air as a tool for annotating a videoconference. If you're the live or post-facto scribe for a meeting, it's a great way to contextualize your summary with pointers to the relevant parts of the discussion. Scrubbing around in the video and capturing "Get video at current time" links couldn't be much easier. But video is an opaque data type that we can't easily scan or search.

    Text, on the other hand, is eminently scannable and searchable. Given a high-quality transcript with embedded timecodes that align individual words to corresponding points in the video, you could use that transcript as an interface to an audio editor. That's something I've long imagined, but won't experience anytime soon. Right?

    To read this article in full or to leave a comment, please click here

    by Jon Udell at May 04, 2015 10:00 AM

    May 03, 2015

    Lambda the Ultimate

    BER MetaOCaml -- an OCaml dialect for multi-stage programming

    BER MetaOCaml -- an OCaml dialect for multi-stage programming
    Oleg Kiselyov
    2010-2015-

    BER MetaOCaml is a conservative extension of OCaml for ``writing programs that generate programs''. BER MetaOCaml adds to OCaml the type of code values (denoting ``program code'', or future-stage computations), and two basic constructs to build them: quoting and splicing. The generated code can be printed, stored in a file -- or compiled and linked-back to the running program, thus implementing run-time code optimization. A well-typed BER MetaOCaml program generates only well-scoped and well-typed programs: The generated code shall compile without type errors. The generated code may run in the future but it is type checked now. BER MetaOCaml is a complete re-implementation of the original MetaOCaml by Walid Taha, Cristiano Calcagno and collaborators.

    Introduction to staging and MetaOCaml

    The standard example of meta-programming -- the running example of A.P.Ershov's 1977 paper that begat partial evaluation -- is the power function, computing x^n. In OCaml:

    let square x = x * x
    
    let rec power n x =
      if n = 0 then 1
      else if n mod 2 = 0 then square (power (n/2) x)
      else x * (power (n-1) x)
    

    [...]

    In MetaOCaml, we may also specialize the power function to a particular value n, obtaining the code which will later receive x and compute x^n. We re-write power n x annotating expressions as computed `now' (when n is known) or `later' (when x is given).

    let rec spower n x =
      if n = 0 then .<1>.
      else if n mod 2 = 0 then .<square .~(spower (n/2) x)>.
      else .<.~x * .~(spower (n-1) x)>.;;
    
    A brief history of (BER) MetaOCaml

    As MetaOCaml was being developed, new versions of the mainline OCaml were released with sometimes many fixes and improvements. The MetaOCaml team tracked new OCaml releases and merged the changes into MetaOCaml. (The MetaOCaml version number has as its base OCaml's release version.) The merge was not painless. For example, any new function in the OCaml compiler that dealt with Parsetree (AST) or Typedtree has to be modified to handle MetaOCaml extensions to these data structures. The merge process became more and more painful as the two languages diverged. For instance, native code compilation that first appeared in MetaOCaml 3.07 relied on SCaml, a large set of patches to OCaml by malc at pulsesoft.com to support dynamic linking. OCaml 3.08 brought many changes that were incompatible with SCaml. Therefore, in MetaOCaml 3.08 the native compilation mode was broken. The mode was brought back in the Summer 2005, by re-engineering the SCaml patch and implementing the needed parts of dynamic linking without any modification to the OCaml code. The revived native compilation has survived through the end.

    [...]

    BER MetaOCaml has been re-structured to minimize the amount of changes to the OCaml type-checker and to separate the `kernel' from the `user-level'. The kernel is a set of patches and additions to OCaml, responsible for producing and type-checking code values. The processing of built code values -- so-called `running' -- is user-level. Currently the user-level metalib supports printing, type-checking, and byte-compiling and linking of code values. Users have added other ways of running the code, for example, compiling it to machine code, C or LLVM -- without any need to hack into (Meta)OCaml or even recompile it.

    [...]

    By relying on attributes, the feature of OCaml 4.02, BER N102 has become much closer integrated with OCaml. It is instructive to compare the amount of changes BER MetaOCaml makes to the OCaml distribution. The previous version (BER N101) modified 32 OCaml files. The new BER N102 modifies only 7 (that number could be further reduced to only 2; the only file with nontrivial modifications is typing/typecore.ml). It is now a distinct possibility that -- with small hooks that may be provided in the future OCaml versions -- MetaOCaml becomes just a regular library or a plug-in, rather being a fork.

    May 03, 2015 04:16 PM

    Giles Bowkett

    Two More Videos About Synthesizers

    In this video, I show how a Microbrute sound works. I might use this for my upcoming class.



    This is just a video of Mutable Instruments' Peaks and Frames modulating a bass line played by a Microbrute.

    by Giles Bowkett (noreply@blogger.com) at May 03, 2015 10:56 AM

    May 02, 2015

    Mark Bernstein

    660

    A-Rod got his 660th, tying Willie Mays. No one seems all that excited.

    I remember when Aaron broke Ruth’s record. That was a big deal, in part because Ruth’s record had stood for so long, in part because Ruth was the greatest player in history. Aaron wasn’t the greatest player, though he was great.

    Then Bonds broke Aaron’s record, to much hissing. The catch here is simply that you can argue that Bonds was the greatest hitter in history. Because of steroids, and because he hasn’t been easy to get along with, no one really wants to make the argument. But the argument’s there in the record book: you could look it up.

    And now here’s A-Rod, passing the Say-Hey Kid. It ought to be a good time, a time to look back to the Polo Grounds and the Vic Mertz catch and 660. That’s a lot of homers!

    I think we really need to stop obsessing with pills. We accept all sorts of other kinds of sports medicine. We accept cheating: no one ever accused Ty Cobb of playing fair, and we’re not ignoring his records. It’s a game.

    May 02, 2015 03:41 PM

    Tim Ferriss

    TF-StitcherButton

    Vessel_-_How_to_Hack_and_Win_Online_DatingHacker Samy Kamkar in “The Dating Game”

    Samy Kamkar is one of the most innovative and notorious computer hackers in the United States. He’s also a well-known whistleblower. If you want to learn how Samy hacks everything from online dating to car alarms, this episode is for you.

    He is best known for creating the fastest spreading virus of all time, a MySpace worm named “Samy.” He got raided by the United States Secret Service for that one. More recently, he’s created SkyJack, a custom drone that hacks into any nearby drones, allowing him (or any operator) to control a swarm of devices; and Evercookie, which appeared in top-secret NSA documents revealed by Edward Snowden. He also discovered illicit mobile phone tracking by Apple iPhone, Google Android and Microsoft Windows Phone mobile devices.

    His research and findings led to a series of class-action lawsuits against these companies and a privacy hearing on Capitol Hill.

    To see Samy help me hack my online dating, click here for the “Dating Game” episode of my new TV show.

    But to get us started, here is an epic, wine-fueled conversation with Samy about all things hacking-related…

    TF-ItunesButton TF-StitcherButton

    As a bonus, here are other podcast episodes from experts who appear in The Tim Ferriss Experiment: Josh Waitzkin (Chess Prodigy + Brazilian Jiu-Jitsu), Neil Strauss (The Game), and Ed Cooke (Memory Champion).

    Don’t miss Samy’s site, his outstanding YouTube channel, and his Twitter.

    This podcast is brought to you by Mizzen + Main. Mizzen + Main makes the only “dress” shirts I now travel with — fancy enough for important dinners but made from athletic, sweat-wicking material. No more ironing, no more steaming, no more hassle. Click here for the exact shirts I wear most often.

    This episode is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.

    QUESTION(S) OF THE DAY: What precautions have you taken to protect yourself in a digital world? Please share in the comments here.

    Last, if you haven’t yet seen The Tim Ferriss Experiment, please check it out!  It’s currently the #1 TV show season on iTunes and Apple TV, beating out Game of Thrones, Downton Abbey, and Mad Men (!).  See what the buzz is about.

    Enjoy!

    by Tim Ferriss at May 02, 2015 04:48 AM

    May 01, 2015

    Lambda the Ultimate

    Generating compiler back ends at the snap of a finger

    The paper:

    Resourceable, Retargetable, Modular Instruction Selection Using a Machine-Independent, Type-Based Tiling of Low-Level Intermediate Code

    Ramsey and Dias have a series of papers about making it ever easier to generate compiler backends, and the claim is that they produce decent code to boot. I wonder if this stuff has/will show up in compilers I can use? (Or, do you think it not actually matter, for some pragmatic reason or other?)

    Abstract: We present a novel variation on the standard technique of selecting instructions by tiling an intermediate-code tree. Typical compilers use a different set of tiles for every target machine. By analyzing a formal model of machine-level computation, we have developed a set of tiles that is machine-independent while retaining the expressive power of machine code. Using this tileset, we reduce the number of tilers required from one per machine to one per architectural family (e.g., register architecture or stack architecture). Because the tiler is the part of the instruction selector that is most difficult to reason about, our technique makes it possible to retarget an instruction selector with significantly less effort than standard techniques. Retargeting effort is further reduced by applying an earlier result which generates the machine-dependent implementation of our tileset automatically from a declarative description of instructions' semantics. Our design has the additional benefit of enabling modular reasoning about three aspects of code generation that are not typically separated: the semantics of the compiler's intermediate representation, the semantics of the target instruction set, and the techniques needed to generate good target code.

    May 01, 2015 10:28 PM

    Alarming Development

    Future Programming Workshop 2015

    The Future Programming Workshop will return this year to SPLASH and Strange Loop. See http://www.future-programming.org/call.html. This year we are taking any kind of media, not just videos. Web pages and papers are welcome too. By request of the academic members of our community we will publish proceedings containing the paper-format submissions. We are applying for permission to publish the proceedings in the ACM Digital Library but will go somewhere else if necessary.

    Like last year we will offer the option to present at the Strange Loop pre-conference FPWxELC event. Unlike last year there will also be a chance to present publicly at SPLASH. The SPLASH event will be two days: the first for public presentations and the second for the private writers’ workshop.

    Thanks to Richard Gabriel and Alex Payne for teaming up with me to make this happen.

    Submission deadline is August 7 (pre-submit July 19 for Strange Loop). So get to work and show us what you’ve got!

    by Jonathan Edwards at May 01, 2015 07:18 PM

    Dave Winer

    Professional users

    I love testers. Great testers are essential. Or you could look at them as professional users. Or something else. But without them, software projects flounder.

    One of the things I said to Doc yesterday is that if you can write a good bug report you'll do better as a user, because the problems you're hitting will move to the front of the queue. If I, as a developer, get a set of reproducible steps, that show how to recreate the problem, and steps work on my machine, I can usually fix the problem straight away. And I like to fix problems in my code.

    The best user/tester I've ever worked with was Terry Teague. He had a day job at Apple as a tester, but contributed his time for free to various developer projects. We were lucky to have him as part of our team on Frontier. When we were preparing a new release, he'd put the product through its paces, and his bug reports were the best, hands down. Never seen anything like it. His steps-to-reproduce were clear, easy to follow, and almost always failed on my machine (failure in this case is success).

    Unfortunately Terry died in 2005. And he's never been replaced.

    We should be teaching young people how to be great users. How to contribute to the projects that make them more effective at doing what they do. The best form of contribution is to communicate clearly about ways the software isn't working.

    There's a common, incorrect, belief that users don't matter, they can't do anything to help open source projects. Nothing could be further from the truth. Just having one user put a bit of serious concentrated time in working on my product made a huge difference for me as a developer. If Doc hadn't been willing to come to the phone and work with me, the problem would still be in the software. Who knows how many users suffered silently with this, or worse, just stopped using the product because they thought it was sabotaging their work (in a way it was). And how many more problems are waiting to be discovered, waiting until a user cares enough to get to the bottom of what input is producing the bad output.

    Bottom-line: Software needs users to care about it.

    May 01, 2015 01:02 PM

    Greg Linden

    Quick links

    Some of the best of what I've been thinking about lately:
    • Amazon now has 109 warehouses and 165k employees. Wow. ([1])

    • Amazon cloud computing has 17% operating margins, surprisingly high given all the competition ([1] [2])

    • Microsoft appears to be claiming they're going to be bigger than Amazon AWS in three years ([1])

    • But Amazon's Andy Jassy says, "One of the biggest surprises around this business has been how long it took the old guard companies to try and pursue an offering. None of us thought we would get a seven-year head start.” ([1])

    • Apple is the iPhone ([1])

    • Great article on the history of YouTube: "It's easy to forget YouTube almost didn't make it" ([1])

    • Mobile ads still aren't targeted (unlike Web ads) ([1] [2])

    • Browsers are disabling Java and Silverlight by default, and Flash's days might be numbered ([1])

    • Surprising how few people use their mobile to get directions, look up public transit, or request a taxi ([1])

    • A major predictor of how much people like a picture of a face is how sharp and clear the eyes are in the photo ([1])

    • Successful tests of a bullet-sized guided missile, cool but very scary ([1] [2])

    • "If an election was hacked any time in the past, we will never know" ([1])

    • "Maybe this head-up display for your life starts as a head-up display for your car" ([1])

    • Beginning of the end for radio: "Norway the first country in the world to 'decide upon an analogue switch-off for all major radio channels'" ([1])

    • A new trend in biology, collecting large amounts of data and doing A/B testing ([1] [2])

    by Greg Linden (noreply@blogger.com) at May 01, 2015 12:57 PM

    April 30, 2015

    Dave Winer

    "Reproducible"

    A few weeks back, Doc posted a mysterious message to our support list, saying that blank headlines were showing up in his outline, and wanted to know if we knew what the problem was.

    This is the kind of "bug report" that makes programming for users so frustrating. You hear a user is losing data, but have absolutely no idea how to reproduce the problem. It's something you've never seen the software do, can't imagine it actually doing. The description sounds like magic, but nothing in software happens by magic, all programmers will tell you. I believe it's happening but I have no idea why.

    Anyway, the problem was still happening. We needed to get to the bottom of it. So I added a bit of instrumentation to the app. Every second it would look at all the headlines in the outline and count the number of empty ones, displaying the result on the screen. If it was greater than zero the message would show up in red. I wanted to be sure Doc would see it, the instant it happened.

    I called him on Skype and said he should use the software as normal, and when he saw the number go above zero, to stop and think What Did I Just Do, and write me an email. This was my hope to try to get somewhere in the vicinity of reproducible.

    He said it's reporting 9 empty headlines now. Okay, go through the outline, find them and fix them. Get that number down to 0 so we can start debugging.

    So he did, and we talked a bit about this process while he was doing it.

    Then when he was done, he was mousing around the outline and it happened. A headline disappeared.

    I said loudly, now stop! Don't touch anything. Key question: What were you doing?

    He said he was scrolling around the outline and scrolled back to the top and that was when he discovered the headline was empty.

    Turns out it was very important just how he was scrolling around. He was using Pageup and Pagedown, two keys I never use. But for Doc they're central. And when he'd press Pageup or Pagedown, it would wipe out the bar cursor headline. Bing!

    Would it do it on my machine? Drumroll please -- yes it would. So now the bug was trapped. I told Doc we had arrived at the Holy Moment in debugging -- reproducibility. I told him "reproducible" is the programmer's favorite word. If you can tell me the steps to reproduce the problem, then I can find it and fix it. Until it's reproducible all I can do is share your frustration.

    There's a lot more to say about this. I asked Doc to write this up from his point of view. For me it was a breakthrough. Finally, a user who is working on the team with me, to help make the software work better.

    April 30, 2015 09:56 PM

    Mark Bernstein

    Treemaps

    Treemaps

    I’ve been working on a new Treemap View for Tinderbox. Here’s an example:

    Treemaps
    Click here for full size

    What we have here is a section of a Tinderbox note file that contains lots of expense reports from a fictional business trip. Each expense is a box. The area of each box is proportional to the expenditure, scaled logarithmically. The color of each box is proportional to the number of words used to justify the expense to Accounting.

    We’ve got more the fifty notes on view view here – more than we could get onscreen with a outline – and a nice mix of hierarchical structure, visualization, and clarity. Big documents reveal some interesting structure, too; here’s my weblog:

    Treemaps

    There’s a good deal of work remaining to do, but it’s shaping up nicely.

    April 30, 2015 08:39 PM

    Writing And Time

    Adam Gopnik:

    Writing is turning time into language, and all good writers have an elaborate, fetishistic relationship to their working hours. Writers talking about time are like painters talking about unprimed canvas and pigments. (Nor is there anything philistine about writers talking money. Inside the ballroom at the PEN banquet, it’s all freedom and dignity; outside, it’s all advances.)

    April 30, 2015 05:51 PM

    The Last Days of California

    An eerily modern Pilgrim’s Progress in which a plain 15-year-old girl is dragged along on a family car trip, starting from their sourly-sweet Alabama home and heading for Oakland, California where, in five days, the Rapture will commence. Dad has lost his job, though the two girls aren’t supposed to know that. Mom has pretty much lost whatever affection she had for Dad, though the two girl’s aren’t supposed to know that, either. Elise, seventeen and beautiful, is pregnant, though Mom and Dad aren’t supposed to know that. And the narrator, Jess Metcalf, has pretty much concluded that it’s all a crock: beauty, true love, goodness, Jesus, fast food, all of it. She learns a lot on the road, but never loses a certain clarity of vision.

    Why hadn’t he texted me? I hoped he didn’t think I was just some girl who had given him a handjob in the back of his van. I was, of course, but I couldn’t think of myself that way, and couldn’t think of him thinking of me that way, either.

    Then again, fast food is pretty good.

    April 30, 2015 02:31 PM

    Fog Creek

    Software Development Metrics – Interview with David Nicolette

    .little {font-size: 75%}
    Software Development Metrics – Interview with David Nicolette

    Looking for audio only? Listen on

    We’ve interviewed Dave Nicolette, a consultant specializing in improving software development and delivery methods and author of ‘Software Development Metrics’. We dive into what factors to consider when selecting metrics, examples of useful metrics for Waterfall and Agile development teams, as well as common mistakes in applying metrics. He writes about software development and delivery on his blog.

    Content and Timings

    • Introduction (0:00)
    • About David (0:21)
    • Factors When Selecting Metrics (3:22)
    • Metrics for Agile Teams (6:37)
    • Metrics for Hybrid Waterfall-Agile Teams (7:37)
    • Optimizing Kanban Processes (8:43)
    • Rolling-up Metrics for Development Management (10:15)
    • Common Mistakes with Metrics (11:47)
    • Recommended Resources (14:30)

    Transcript

    Introduction

    Derrick:
    David is a consultant specializing in improving software development and delivery methods. With more than 30 years experience working in IT, his career has spanned both technical and management roles. He regularly speaks at conferences, and is the author of ‘Software Development Metrics’. David, thank you so much for taking your time out of your day to join us. Why don’t you say a bit about yourself?

    About David

    David:
    I’ve been involved with software for a while and I still enjoy it, though I’ve been working as a team coach and organizational coach, technical coach, for a few years. I enjoy that.

    Derrick:
    Picking up on the book ‘Software Development Metrics’, what made you want to write the book?

    David:
    It’s an interesting question, because I don’t actually find metrics to be an interesting topic, but I think it is a necessary thing. It’s part of the necessary overhead for delivering. If we can detect emerging delivery risks early, then we can deal with them. If we don’t discover them until late, then we’re just blindsided and projects can fail. It’s important to measure the right things and be sure we’re on track.

    Secondly, I think it’s important to measure improvement efforts, because otherwise we know we’re changing things and we know whether they feel good, but we don’t know if they’re real improvements if we can’t quantify that. I noticed several years ago that a lot of managers and team leads and people like that didn’t really know what to measure. I started to take an interest in that, and I started to give some presentations about it, and I was very surprised at the response because quite often it would be standing room only and people wouldn’t want to leave at the end of the session. They had more and more questions. It was as if people really had a thirst for figuring out what to measure and how. I looked at some of the books that were out there and websites that were out there, and they tended to be either theoretical or optimistic.

    Derrick:
    Metrics for measuring and monitoring software development have been around for decades, but a lot of people still don’t use them effectively. Why do you think that is?

    David:
    I often see a pattern that when people adopted new process or method, unfamiliar one, they try to use the metrics that are recommended with that process. There are a couple of issues that I see. One is that they may only be using the process in name only, or they’re trying to use it but they’re not used to it yet, and the metrics don’t quite work because they’re not quite doing the process right.

    The other issue is that people tend to use the measurements that they’re accustomed to. They’ve always measured in a certain way, now they’re adopting a new process. They keep measuring the same things as before, but now they’re doing the work in a different way. There’s a mismatch between the way the work flows and the way it’s being measured. They have numbers and they rely on the numbers, but the numbers are not telling truth because they don’t line up with the way the work actually flows.

    Factors When Selecting Software Development Metrics

    Derrick:
    Picking the right metrics is paramount. What are some of the factors that we should consider when selecting metrics?

    David:
    Look at the way work actually flows in your organization and measure that. I came up with a model for that in the course of developing this material which I would look at three factors to try to judge which metrics are appropriate. The first factor is the approach to delivery. The basic idea there is if you try to identify all the risks in advance, all the costs, you identify all the tasks, lay out a master plan, and you follow that plan. That’s what I’m calling traditional.

    What I call adaptive is a little different. You define a business capability, you’ve got your customer needs, and you set a direction for moving toward that, and you steer the work according to feedback from your customer, from your stakeholders. You don’t start with a comprehensive plan, you start with a direction and an idea of how to proceed. Then you solicit feedback frequently so you can make course corrections. That’s the first factor I would look at: traditional versus adaptive, and that I think has the biggest impact on which metrics will work.

    The second factor to look at is the process model. I don’t have to tell you that there are a million different processes and nobody does anything in a pure way, but if you boil it down I think there’s basically four reference models we can consider, or process models. One is linear, you can imagine what that is. The canonical steps that go through from requirements through support. The next one would be iterative, in which you revisit the requirements multiple times and do something with them. The third one that I identify is time-boxed. It’s really popular nowadays with processes like Scrum and so on. The fourth one is continuous flow. This is becoming popular now with the Kanban method, and it’s also being adapted into Scrum teams quite a lot. We’re really interested in keeping the work moving smoothly.

    Now a real process is going to be a hybrid of these, but it’s been my observation that any real process will lean more toward one of those models than the others, and that’ll give us some hints about what kind of metrics will fit that situation. The third thing probably has the least impact on is whether you’re doing discreet projects or continuous delivery. What some people call a continuous beta, or some people just don’t have projects. You have teams organized around product lines or value streams, and they continually support them, call it a stream. Between those two there are some differences in what you can measure. Well I look at those three factors, and based on that you can come up with a pretty good starter set of things to measure, and then you can adapt as you go from there.

    Metrics for Agile Teams

    Derrick:
    Let’s take a couple of example scenarios. If we have an agile team working in short sprints who are struggling to ship a new product, what kind of metrics should they consider to identify areas for improvement?

    David:
    If they’re using Scrum basically correctly, they could probably depend on the canonical metrics that go with that, like velocity and your burn chart. You might look for hangover, incomplete work at the end of the sprint. You might look for a lot of variation in story size, when you finish a story in one day and the next story takes eight days. When it comes to metrics as such they could use, as I said, velocity and so on, and you can always use lean-based metrics because they’re not really dependent on the process model. What they might consider is looking at cycle times. They could look at the mean cycle times as well as the variation in cycle times and get some hints about where to go for root—cause analysis. Metrics don’t tell you what’s wrong, but they can raise a flag.

    Metrics for Hybrid Waterfall-Agile Teams

    Derrick:
    What about a hybrid waterfall agile team working on a long term project, wanting to know what it’s possible to deliver by a certain date?

    David:
    To know what’s possible to deliver you can use the usual things like a burn chart, burn up or burn down as you prefer, to see according to their demonstrated delivery, their velocity, I’ll call it that, how much scope they can deliver by a given date. Conversely you could see by what date approximately they could deliver a given amount of scope. It depends on what’s flexible. In this kind of a project, usually neither is flexible, but at least you can get an early warning of delivery risk. If it looks like the trend line is way out of bounds with the plan, well now you’ve got a problem.

    One thing that might surprise some people is the idea that agile methods can be used with traditional development. We need to decouple the word “agile” from “adaptive,” because quite often it is used in a traditional context.

    Optimizing Kanban Processes

    Derrick:
    What are some metrics relevant to those working in a bug queue? Say they’re wanting to optimize their working practices to stay on top of incoming bugs.

    David:
    For that I usually like to use little metrics, mainly cycle time, because you want to be somewhat predictable in your service time so when a bug report comes in people have an idea of when they can expect to see it fixed. How do you do that? Well, you can use empirical information from past performance with fixing bugs, and your mean cycle time will give you approximately how long it takes to fix one.

    I like to use the Kanban method for these kind of teams because it defines classes of service. You’ll find that every type of bug doesn’t take the same amount of time to fix. Based on your history, pick out different categories. You can identify the characteristics of particular kinds of bug reports that tend to fall together, and you can track cycle times differently for each of those classes of service. If someone calls in and says, “Well we got this problem.” “Well that looks like that’s in category two. Whatever that means, that typically takes us between four hours and eight hours.” That can give them a little bit of warm fuzzy feeling about when they’re going to see it fixed. I think that using empirical data and tracking cycle time, is the simplest, most practical way toward that workflow.

    Rolling-up Metrics for Development Management

    Derrick:
    What about a CTO who wants to monitor how teams are performing, and ensure code is of high quality? How can metrics be rolled-up for those in more senior positions?

    David:
    How the teams are performing, you need measurements that are comparable across teams and comparable across projects. The lean-based metrics needed to compare across teams and projects and across development and support, those kinds of things. If you’re tracking throughput, cycle time, there’s another one I haven’t mentioned that I wanted to: process cycle efficiency. If you track those, those roll up nice. Some other metrics don’t roll up so well. Some of the agile metrics, particularly velocity is really different for each team. Percentage of scope complete, that may not roll up very well either.

    The other question about code quality, I think that if we can let that be a team responsibility then they can use metrics, but they don’t need to report outward from the team. Usually things that they can get out of static code analysis tools will help them spot potential quality issues, but I wouldn’t share very detailed things like static code analysis kind of stuff and code coverage outside the team, because then team members will fell like they’re going to get judged on that and they’ll start gaming the numbers thinking they’re going to be needed those. Those kind of metrics are really for the team’s own use.

    Common Mistakes with Software Development Metrics

    Derrick:
    What are some mistakes you often see people make when applying software development metrics?

    David:
    People seem to make a couple of mistakes over and over. The one I think I mentioned earlier, people apply metrics that won’t fit the context. Maybe a company wants to ‘go agile’, and so they start tracking agile metrics, so whatever is recommended. The metrics that are recommended are safe or something like that, but they haven’t really fully adopted these new methods. They’re still in the transition, and so the numbers don’t mean what they’re supposed to mean. For instance, they may track velocity, but they might not have feature teams. They might have component teams, and the work items that those teams complete are not vertical slices of functionality. Whatever they’re tracking as velocity isn’t really velocity. You start getting surprised by delivery issues.

    You can also have the opposite situation where teams are working in an agile way, but management is still clinging to traditional metrics. They will demand that the teams report percentage of still complete to date, but you’re doing adaptive development so you don’t have 100 percentage scope defined. You have a direction. You may be 50% complete this week based on what you know of the scope. Next week you might be 40% complete because you’ve learned something, and then the management says “Well what’s going on? You’re going backwards,” and they don’t understand what the numbers mean. What I see happen in that case is it drives the teams away from adaptive development, and causes them to try to get more requirements defined upfront.

    The second mistake I see a lot is that people either overlook or underestimate the effects of measurement on behavior. We can be measuring something for some objective reason, but it causes people to behave differently because they’re afraid they’re going to get their performance review will be bad because they didn’t meet their numbers. I think we have to be very conscious of that. We don’t want to drive undesired behaviors because we’re measuring things a certain way. That not only breaks morale, but it also makes the measurements kind of useless too when they’re not real.

    Those are really the two main mistakes: that they don’t match up the metrics with their actual process, or they neglect the behavioral effect of the metric.

    Recommended Resources

    Derrick:
    What are some resources you can recommend for those interested in learning more about managing projects and improving processes?

    David:
    I like this, an older book called ‘Software By Numbers’. That’s a classic, but one of David Anderson’s earlier books is called ‘Agile Management From Software Engineering’. That has a lot of really good information to apply economic thinking to different kinds of process models. He covers things like feature driven development, extreme programming. Another guy whose work I like is Don Reinertsen. He combines really deep expertise in statistics with deep expertise in economics and applies that to software, and can demonstrate mathematically why we don’t want to over-allocate teams. How it slows down the work if you load everybody up to 100% actually slows things down. What’s counter intuitive to a lot of managers is if you load your teams to 70% capacity they’ll actually deliver better throughput, but it’s very hard for a lot of managers to see somebody not busy. It’s really hard for them to get there.

    Derrick:
    Really appreciate your time today Dave, some great stuff here. Thank you.

    David:
    Well I enjoyed the conversation, thanks.

    by Gareth Wilson at April 30, 2015 10:53 AM

    April 29, 2015

    Mark Bernstein

    Outlining With Tinderbox

    Outlining With Tinderbox

    A deep introduction by Steve Zeoli.

    I was going to end this overview by saying that Tinderbox is not the world’s best Mac outliner. But I’ve changed my mind. I think it is the best, when you consider all it has to offer.

    April 29, 2015 08:51 PM

    Dave Winer

    Scoble asks about the Facebook API

    Over on Facebook, my friend Robert Scoble asked how I feel about changes Facebook is making in developer access to the social graph. It was such an interesting question that I did a 10-minute podcast answering the question. Hope you find it interesting!

    April 29, 2015 07:57 PM

    April 28, 2015

    Tim Ferriss

    Tim Ferriss

    [PLEASE NOTE: This contest has ended per the rules explained below. Thanks!]

    I cannot put into words how excited I am to write this post. Perhaps it’s because I’ve had 3 glasses of wine, or perhaps it’s the glee of F bombs below.

    But no.

    It’s because I have a huge TV announcement, an opportunity to get a personalized video from Arnold Schwarzenegger (seriously), and much more.

    Short and sweet — I FINALLY got digital rights to my TV show, The Tim Ferriss Experiment. It’s about how to conquer fear in any skill and 10x your learning speed. Think of it as Mythbusters meets Jason Bourne. Filmed and edited by the Emmy award-winning team behind Anthony Bourdain (Zero Point Zero).

    It took eons of negotiating and lawyering, but I got digital rights for you guys, at long last.

    This is my most important project of the last three years. It literally took blood, sweat, and tears. You’ll see my horrible injuries when you watch the show. In the parkour episode alone, I tore both ACLs, 6 of my 8 total quadriceps muscles (both legs), my rotator cuff muscles, and all the flexors in one forearm.

    If you’ve gotten any value from me over the years, could you please buy the season pass for this fuckin’ show? :) Click here to get 13 episodes for next to nothing. It’s cinematic, insane, and won’t disappoint. Here is all the craziness, including a free preview. In a nutshell:

    Bestselling author Tim Ferriss (“The world’s best human guinea pig.” – Newsweek) pushes himself to the breaking point, attempting to learn notoriously punishing skills–surfing, professional poker, Brazilian jiu-jitsu, parkour, languages, etc.–in just one week each.

    In every episode of The Tim Ferriss Experiment, Ferriss partners with the world’s best and most unorthodox teachers (Laird Hamilton, Marcelo Garcia, Stewart Copeland, etc.), who train him for a final gauntlet. Shocking breakthroughs, injuries, epiphanies, and disasters ensue. In cases where he succeeds, Tim shows you how to replicate his results. The mantra of the show is “you don’t need to be superhuman to get superhuman results…you just need a better toolkit.”

    I’m too tired to hide my Long Island pedigree, so… please just buy this season pass here. You’ll fucking love it.

    A few things to sweeten the pot…

    Arnold Schwarzenegger and Glitch Mob Craziness

    I don’t half-ass launches. I go whole ass. Perhaps even 110% ass. So here’s the deal:

    I want EVERYONE to see this show. I’m super proud of it, and your support means the world to me. 2nd place is 1st loser in my mind, so I’m going all out.

    To the person who promotes the show best (details below), I’m giving away two priceless prizes, both from icons:

    1) You’ll get a personalized motivational video from the Terminator, the man who killed the Predator (for God’s sake, people!) — Arnold Schwarzenegger. If you want to slay dragons and become superhuman, Arnie can motivate you like no one else. He’ll record a video to psyche you to greatness.

    2) You’ll get a custom “anthem” from one of the biggest electronic music groups in the world — The Glitch Mob! Band members Boreta and Ooah will create ~30 seconds of awesomeness, a worldwide original just for you. Use it to get amped to do incredible things. Listen to it every morning, listen to it when you need to kick ass, listen to it before workouts or whenever you need extra juice. No one can buy this.

    Are you fucking kidding me? No, I am not. The above two are real.

    And you can feel good about promoting and buying the show, as 25% of all launch week profits for the TV show go to After-School All-Stars, which supports after-school programs for at-risk youth who need mentors. They do amazing work, and I recognize how a few mentors steered me from disaster early in my life. I want everyone to have that opportunity.

    So… how do you win these bonzo garbanzo bonuses?

    1) Promote the hell out of The Tim Ferriss Experiment this week, driving clicks to the iTunes page: itunes.com/timferriss  Here’s one step to get you started.

    2) Leave a comment on this post telling me what you did (including anything quantifiable), no later than this Sunday, May 3rd 2015, at 10pm PT. Comments must be submitted by 10pm PT. It’s OK if they’re in moderation and don’t appear live before 10pm. Note: You must include “#TFX” at the TOP of your comment to be considered! This is an IQ test on following directions.

    3) By May 10th, I and my panel of magic elves will select the winner: he or she who describes in their comment how they drove the most downloads/listens. If you drive people to buy season passes, you get major bonus points.

    4) That’s it! Remember: Deadline is 10pm PT on May 3rd. No extensions and no excuses.

    5) Of course, void where prohibited, no purchase required, you must be over 21, no minotaurs, etc.

    But That’s Not All… (Cue Rotisserie Chicken)

    If you simply buy the season pass, you can get a bunch of awesome stuff. Put another way, if you spend $14.99 USD, you get more than $200 in bonuses.  Here are the deets:

    Important note #1: This only applies to people within the United States, or in US territories. Alas, I could only get rights for the US, so this is only available to residents of the US and US territories for now.  The network wouldn’t give me international rights, but I spent a small fortune trying.  I’ll keep trying.

    Important note #2: Most of these prizes will be delivered by May 10th. You’ll receive confirmation and a remind about all of this, but when you purchase and submit proof of purchase, please be patient.

    1) If you buy the full season pass of the Tim Ferriss Experiment, you will receive all of the below prizes.

    2) When you purchase the full season (remember, single episodes don’t count), you’ll be sent goodies including:

    CreativeLive: A $50 free credit + course from Neil Strauss on the creative process

    CreativeLive is an online learning platform that broadcasts live, high-definition classes to more than 2 million students in 200 countries. The classes are amazing. Teachers include Pulitzer Prize winners, business luminaries, and more.  Neil Strauss, author of The Game, was one of my teachers for the “Dating Game” episode of The Tim Ferriss Experiment.

    90-day free trial + a $200 coupon for WebinarJam

    If you run any type of online business, WebinarJam Studio is a vital tool for entrepreneurs, which allows you to reach an unlimited number of people. The service is turnkey in terms of creating better conversions, allowing you to upload to YouTube, and integrate with your email list.

    The Tim Ferriss Show Transcripts

    It’s taken a long time, but I finally have transcripts from my “Best of iTunes 2014″ podcast. Not just that, but I’ve put them together into a pretty e-book PDF of 600+ pages. These are never-before-released transcripts of 25 of the most popular episodes of The Tim Ferriss Show, including episodes featuring Arnold Schwarzenegger, Triple H, Jon Favreau and more.

    ChefSteps: Free high-def cooking classes (don’t ignore this)

    This was an invaluable resource for me when I was writing and research The 4-Hour Chef. ChefSteps is a James Beard Award–winning team of chefs, filmmakers, designers, writers, and scientists on a mission to help people cook smarter. ChefSteps.com and its companion app are designed to inspire creativity in the kitchen through high-quality interactive content, classes, tools, and resources that will inspire and educate cooks at any skill level.

    [REMINDER: This contest is now over per the rules above. Thanks!]

    And that’s the whole story!

    Still wondering what I’m talking about?  Here you go.

    I hope you love watching it as much as I enjoyed making it!

    Much love and high fives from California,

    Timbo

    by Tim Ferriss at April 28, 2015 09:30 AM

    Fog Creek

    Getting Started with Iteration Planner for Agile and Sprint Planning in FogBugz

    We recently released Iteration Planner. It unlocks the power of FogBugz as an Agile planning tool for software development. With it you can combine sprints and milestones to graphically group cases into the scope of work that you’ll complete in each sprint. You can also balance the allocation of resources by dragging and dropping cases from one assignee to another. Iteration Planner is a lightweight way to plan work and manage teams using FogBugz. Here are a few key details to help you get started with it.

    Create or Convert from the plugin a Backlog milestone

    If you are converting your FogBugz instance to the newest version and you want to use the same backlog order that you were using with the backlog plugin, you’ll need to click “Add Milestone”; locate your backlog milestone; add it to the Iteration Planner display. Your cases will appear in the order that they were ranked with the plugin.

    Populate the Backlog

    You can add cases to your milestones by dragging and dropping them either from the search results column or from other milestones, for example, Backlog; or Sprint x.

    Order the backlog

    By dragging and dropping cases within a milestone, you can change the case sort order for that milestone. The case sort order is independent of the selected grouping: assignee, status, or priority. This order should be understood by the team as the order in which the cases will be completed.

    Create a sprint

    In Agile software development methodology, a sprint is a fixed unit of time in which a scope of work will be done. FogBugz uses milestones to represent Agile sprints. Cases grouped together in a milestone describe the scope of work to be done within the interval of the sprint.

    Populate Sprints with cases

    You can acquire cases by searching for them and dragging them out of the search results column; pulling them from your Backlog or some other milestone; creating them as new cases by using the “create case” button attached to the bottom of each of the milestones.

    Iteration Planner with Backlog and sprint milestones created

    Estimate Sprint cases

    We suggest carefully scrutinizing the sum of all of the estimates included in a particular sprint. That number is the estimated amount of time it will take to complete the scope of work which defines your sprint. Whether you are playing planning poker or timeboxing a discovery period that allows developers to decompose the user stories into discrete tasks, estimates will be key to determining your team’s velocity and probable finish date.

    Confirm the Priority of the cases

    Confirm, with the major stakeholders, your assumptions about which cases comprise the minimum viable product (MVP) for each sprint. Assign the top 3 priority levels to your MVP. Group other, non-MVP, cases to be done during the sprint under the remaining four priorities provided by FogBugz (see below, “suggestions for applying priorities”)

    Balance Allocations

    When you sort a sprint by assignee, note the number of hours given staffing levels that are available in a sprint; pare the scope and switch assignees where necessary in order to ensure there is enough time in your sprint to accomplish your MVP. Drop the excess cases back into the Backlog (Rejoice, you now have more estimated cases in the backlog!) based on the amount of time you have for the sprint and the estimates of the work to be completed during the sprint.

    Sorted by assignee

    Use Time Tracking

    Using the time tracking feature of FogBugz will allow you to see how much time has been spent on a given case. In the Iteration Planner, this time is subtracted from the estimate and reported as hours remaining.

    Update Iteration Planner with new cases and changes to Priority

    As the team works through the sprint priorities may change and cases may need to be added or subtracted. Updating the Iteration Planner will be a good way to determine and communicate the team’s progress through the sprint. This is not to suggest that the Iteration Planner is an automated wonder that obviates the need for communication among team members. But it is the automated wonder that keeps track of the conversation so that you know which topics require the team’s focus.

    Suggestions for applying priorities

    • 1-3 Minimum Viable Product
      These are all of the cases that must be completed in order for your sprint to provide new value to the customer in the form of a usable feature.
    • Priorities 4: Hygiene
      This is non-essential work that improves the product but is not required in order for the product or feature to be useful to a customer. Small amounts of this work are often spread throughout sprints to continue making small improvements to the product.
    • Priority 5: Incidental work
      Don’t allow your scope to creep from a manageable size to something so huge that it couldn’t be completed in less than a decade by Steve Jobs and a host of efficiency experts. If you add something as incidental work that needs to be done during a sprint you need to subtract or deprioritize some other work that has an equivalent number of estimated hours. Keeping all your incidental cases under one priority allows you to group cases by priority and see how much time you are spending on cases that are not part of your MVP. At the end of your sprint add up the hours and determine whether or not the interrupts were a worthwhile use of your time. This discussion can be part of your retrospectives or done separately. Either way the numbers should be useful for evaluating whether or not the work that was done during the sprint was part of the planned work.
    • Priority 6: Long-range work
      Frequently teams are asked to take on a category of work that is not part of the MVP but does contribute to the overall plans of the organization. These tasks may be expected to take many sprints to complete and their progress needs to be tracked across multiple milestones.
    • Priority 7: Stuff we won’t do
      It’s useful to declare this as a way of focusing the team and managing expectations about the work that will be completed in the sprint.
    Sorted by Priority

    For Agile software development teams, Iteration Planner is a useful, graphical tool that allows you to visually manipulate the information you need for planning Sprints. With it, you can set the direction for your team’s work and monitor progress so you can deliver on your organization’s goals.

    Related Links

    by David Miller at April 28, 2015 08:42 AM

    April 27, 2015

    Mark Bernstein

    42

    I finally saw “42,” which has been overpriced on Amazon and unavailable on Netflix.

    It’s not much of a movie, but the ballpark sets are amazing. You look at the batter digging in for the pitch and, yes, it’s the Polo Grounds! OK: I think that may have been a matte painting, and center field was out of focus – but then, center field at the Polo Grounds was so deep it would have been out of focus. Shibe Park was really impressive. (Oddly enough, I don’t recall any pictures of Ebbets offhand.)

    Oddly enough, they didn’t use anything from the Major League stadium in which Jackie Robinson played in 1947 and which still exists – Wrigley Field. Sure, it’s changed, but it’s changed a lot less than the Polo Grounds.

    April 27, 2015 03:36 PM

    Fog Creek

    dev.life – Interview with Paul M. Jones

    In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

    Today’s guest is Paul M. Jones, the creator of the Aura PHP package library and author of ‘Modernizing Legacy Applications in PHP‘ and ‘Solving The N+1 Problem In PHP‘. He’s a member of PHP-FIG and a founding contributor to the Zend framework.


    Paul M. Jones
    Location: Nashville, TN, US
    Current Role: Architect, Author, Speaker, Trainer

    How did you get into software development?

    I feel very lucky on this front. Some people don’t ever find their true calling in life. I found mine very early.

    In the summer of 1983, just before I turned 13, my parents brought home a TI-99/4A. It was a 3Mhz machine with 16K of RAM and a cassette tape for storage. If you didn’t record your program onto the audio tape, it would vanish when the computer turned off. That setup was practically state-of-the-art for its time. After working with it for about two weeks, I knew what I’d be doing for the rest of my life. I was hooked from the start.

    The TI-994/A came with TI-BASIC, so that was my first language. I remember specifically that you could design your own graphics, but you had to do it by defining your own character sprites on an 8×8 pixel grid. Each row of 8 on/off pixels was represented by a hex code, so you ended up with a series of hex values to define one sprite. I worked that out by coloring in blocks on graph paper, then calculating the hex code for each row. Then you’d use those hex codes as a custom ASCII character to represent a little ship or alien for a game, and print it to the right X/Y position on a 40×24 screen to move it around.

    I spent hours writing out entire programs by hand using paper and pencil, with line numbers at the left and double-spaced. That was so I could work out the flow and edit beforehand because modifying extended blocks of code on the computer itself generally meant retyping entire lines in a line editor.

    So I’m almost entirely self-taught. I picked up TI-BASIC at home. At school, we had some Apple II+ machines (then later some Apple IIe machines as well), which had Apple BASIC and a floppy disk drive. On those, I typed in programs by hand from magazine page listings, mostly games. I also remember one of my math teachers taking my assignment, writing “A” on it without looking, then sending me to the back of the room to work on a programming project he wanted to be done for that hour.

    I learned PASCAL in one of my junior high classes, but I never really used that outside of class. I learned a little Java in a college course, but that was mostly to fill a credit requirement. I picked up HTML, SQL, some Javascript, DBase III and FoxPro, CDML, every consumer program I ever used, Linux, and eventually PHP, all without any formal training. I think my love of the craft helps a lot with that.

    ti

    Tell us a little about your current role

    I have several roles right now: author, speaker, correspondent, open-source project lead, standards advisor, and committee member. I also switch between consultant and employee on a regular basis, depending on what I find interesting or lucrative at a given point.

    I am lucky enough to work from home, and being a man of routine, my days are very similar. They start with me reading my morning news sites over breakfast. Then I’ll amble over to my “office” room to read (and hopefully respond to) incoming emails from overnight and late the day before, over an Espresso and Amaro.

    With correspondence out of the way, I’ll start with whatever the major project is for the day around 9:00 to 9:30am. I’ll try to get in about 3 hours of work time on it. Some days that’s a programming project, other days it’s writing a longish blog post, and still other days it’s working on a book, course, presentation, or proposal. There’s generally some interruption here to respond to IRC or email, and answer questions about a project or a programming problem.

    After that, I’ll break for lunch and a nap, or a barbell workout at the gym and a recovery meal. Then it’s back to the “office” to work on side projects, or perhaps follow through on unfinished work for the morning. That’s generally another 3 hours or so, with an afternoon Espresso and Amaro. If it’s nice outside, I’ll work on the back porch with my dog roaming the backyard or napping at my feet.

    Around 5:30 or 6:00pm I’ll start to cycle out of work mode and into home mode. It’s time for a snack with my girlfriend while we watch an hour of game shows and catch up on each other’s day. Email often intervenes here too, along with reading my end-of-day news sites.

    Later, I’ll have a Martini or Manhattan while we prepare dinner and watch something on Amazon or Netflix. We’re working our way through Supernatural right now. Her tastes generally determine the viewing material, unless I’m inflicting one of the classics on her (“Star Wars”, “Big Trouble In Little China”, “Die Hard”, etc.). Bed is around 10:30 or 11:00pm.

    I am prone to occasional insomnia, usually because some problem from the day has captured my mind, so once a week or so I’ll get up in the middle of the night and sit in front of the computer until I feel drowsy again. It can be frustrating, but it does add a couple hours of reading time to the day.

    I’m always working on Aura in one capacity or another. It’s a continuing labor of love, one that admittedly appeals to a limited set of PHP developers, but they’re the kind of developers I most like working with. The real challenge here for me is marketing. The code and community are fantastic, but the project doesn’t have the widespread “mindshare” that I think it ought to have. Obviously I am not a public-relations genius.

    I just finished an update to ‘Modernizing Legacy Applications in PHP‘. This is its first update since publication last year; it felt really good to incorporate many small changes and clarifications from readers who found it useful and helpful in their work lives. I also just finished a second book, ‘Solving the N+1 Problem in PHP‘. The tough part on these is always sitting down to do the actual writing, and then the editing. “Writing” is tough, but “having written” is awesome. Steven Pressfield’s ‘The War Of Art‘ really helped me in identifying and overcoming what he calls “Resistance” to creative work, and I recommend it to anyone who considers themselves creative.

    Another recent project is Bookdown, a tool for generating Docbook-like HTML output from Markdown and JSON sources. I’d like to spend more time on that to bring it up to 1.0, especially to collect the Aura documentation into a single place.

    My next big project is not exactly a secret, but it’s also not ready for open discussion either. Suffice to say that I’m working with video, and it’s a very different experience for me. When I stand up in front of an audience, there’s a give-and-take of energy between us, and as a performance, there’s a lot of allowance for what feels like a conversation. But with recorded video, there is very little room for error. The exact same presentation is going to be replayed over and over, so every detail has to be exactly right. It’s much more difficult than writing, and I’m having to retrain a lot of my speaking habits because of it.

    When are you at your happiest whilst coding?

    Happiness is not an emotion I associate with programming. My positive emotions there are more like “pride” and “satisfaction”, sometimes even “contentedness”. They rarely last for long, but they are wonderful in the moment.

    Some of my favorite times are when I have refactored something that is spread across the entire application into its own separate space (whether a method or class or layer), and everything continues to work as before. Occasionally that involves a measurable performance improvement, which is a very satisfying feeling.

    Creating order out of chaos, finding patterns in systems, continuous improvement on previous work: these are what give me satisfaction. It takes time, but it gives me great pride to look back and compare “what it used to be” with “what it is now.”

    travisCI

    What is your dev environment?

    It’s pretty spartan. Only in the past couple of years did I switch from TextMate 1 to Sublime 3; before that, it took years for me to switch from BBEdit to TextMate. In Sublime I have the Markdown Preview, Pretty JSON, and Open URL plugins, but that’s about it. Any time I need something more powerful, I’ll generally descend to the command line, and use a crusty old bash script I’ve maintained for years or work some very limited new voodoo. (I am a man of old habits.)

    I’ve been a Mac fan since they existed, and currently use a MacBook Pro mid-2010 that got a little banged up at the tender hands of the TSA. No external monitor, and I still use a wired USB mouse; the trackpads just don’t have the same feel to them.

    Homebrew has become a good friend, and I’ll use that to install most of my other tools: git, mysql, a ton of others that I’m forgetting now. I used to compile PHP by hand, and sometimes still do, but the Homebrew “josegonzalez” PHP packages have been a real time-saver.

    If I’m working on a project for an employer, I’ll set up a Vagrant box that mimics their production environment. If they don’t already have one themselves, I’ll generally make that the first step in working with them. I’ve tried Docker but it just doesn’t appeal to my sensibilities.

    For my own open-source work, I’m a big fan of Travis-CI for the obvious reasons, but especially because it can run tests against multiple versions of PHP. That has made it very easy to keep Aura consistently running on everything from PHP 5.4 up through PHP 7, without me having to maintain each version locally. It’s a fantastic service. Scrutinizer-CI is something I was introduced to last year, and it too has been a great aid to my work. Having an automated review and a measurable score helps me to focus my attention on parts of the code I know are not great, but have ignored because I’ve been too close to them. The dispassionate review discipline it provides is very useful.

    I started using a Gaiam balance-ball chair after beginning my strength-training workouts several years ago. My lower-back flexibility was terrible, and it really showed in my poor barbell squat form. Using the Gaiam has helped immensely.

    I have a couple of internet radio stations for my soundtrack: Groove Salad and Low Mercury, along with a custom collection of music in similar genres. They’re good for helping me to maintain focus and stay in my seat, instead of getting up and walking around aimlessly while pondering.

    What are your favorite books about development?

    My number-one most favorite of all time is The Mythical Man Month by Frederick P. Brooks. I was introduced to it by my Systems Analysis professor, to whom I owe unending gratitude, during my post-military pass through college. That book was written in 1974, and aside from the parts about COBOL, every single bit of it is still true, because human beings have not changed. I expect it to remain true until the Singularity comes (and maybe even after that) for the same reason.

    After that, in no particular order:

    • Peopleware by DeMarco and Lister helped me think more clearly about programming management practices.
    • The Inmates Are Running The Asylum by Cooper convinced me that I, as a developer, should never be allowed to do design work. Conveniently, this suits my temperment.
    • Patterns of Enterprise Application Architecture by Fowler et al., not because it teaches new techniques, but because it gives us a common vocabulary to use when talking about those techniques.
    • The Pragmatic Programmer by Hunt and Thomas, and Code Complete by McConnell, are great fundamental works.
    • Clean Code by Martin is a fantastic capstone work.
    • How To Be A Programmer by Robert L. Read is a tour de force: personal and practical, insightful and inspiring, it is sadly unread and unknown by the vast majority of programmers I have met.

    What technologies are you currently trying out?

    I’d really like an excuse to try out the document-oriented JSON stores in PostgreSQL as an object database. It looks like a really great integration of document features with SQL features. Getting my hands on a Redis installation would be cool, but very little of what I’ve done has actually needed Redis.

    But technologies, per se, are not what really get me going. I like new techniques, and alternative ways of thinking about existing problems that present more elegant or better-separated ways of solving them. That’s one reason I felt so excited about identifying Action-Domain-Responder as a web-specific alternative to MVC. Domain-driven design is another technique that really interests me, and while I’m not very good at it yet, I’d like an excuse to practice it more.

    barbell

    When not coding, what do you like to do?

    I’ve mentioned the gym workouts, which I like much more than I expected to. Barbell training requires a lot of attention to good form, and I find that concentration very rewarding. It’s also a big morale boost to have a physical marker of progress; when you add more weight to the bar each time, you can point to it and see it in the real world. It’s not ephemeral and transitory like code.

    I enjoy doing pistol and rifle work as well, although where I live now that’s a little more difficult to do. It’s very satisfying to line up a shot at a steel target 400 yards away, finish the squeeze on a two-stage trigger, hear the loud “BANG” of the round being fired, then wait through that long moment of silence before the “smack” of the bullet hitting steel comes back to you from across the range. I’m not as consistent as I would like to be, but when it all flows together, it’s beautiful.

    What advice would you give to a younger version of yourself starting out in development?

    Younger Me,
    You consider your mental and intellectual talents as the center of your identity because they come easily to you. You hold in contempt things like social success because they do not come easily to you, but does to others who are not as smart as you. The fact that those others are not as smart, makes you think their social success is of little value in the world. You are wrong. You will be much happier when you use your intellect to retrain yourself into successful social behaviors.

    On hearing that, you will think doing so somehow makes you “untrue to yourself.” This too is a mistake. There are many aspects to your personality. You choose which ones to promote, and which ones to restrain. All of them are “yourself.” Your social powers are atrophied and need exercise for them to become stronger. You will become *more* like your true self, not less, by exercising them.

    Even so, don’t bother too much with that until you get out of high school. Government schools are prison. You have felt this since childhood but never had the words for it. Nothing that happens there will really matter to you later. What matters is you getting out of it.

    Going to college does not count as getting out of it. As a young man, what you need is true self-sufficiency, discipline, and “finishing.” You need something that doesn’t care about your precious little ego, your false sense of self. Join the Air Force out of high school, instead of going to college for 18 months and wasting your time and money by not attending your classes (and then joining anyway from financial pressure). The military experience will burn away all the narrow trivial incidentals of your ego that you think are so important. It will immerse you in a broader world, and leave a strong, resilient, core of “you” focused on larger, better, more important things in life.

    Restrain your workaholism. It is too inwardly-focused, too indulgent of your desire to avoid social situations, and is another exhibition of your intellect as the center of your identity. Yes, you are an intravert, and replenish your energy from being alone. But that need not prevent you from expanding your identity and scope of action in the social world. Apply that intellect and work ethic to training yourself in how to be socially successful; there are great joys to be had there.

    “Socially successful” does not mean “with other people just like you.” It especially does not mean “with your favorite role-playing group of friends.” It does mean, in particular, becoming successful with attractive women. When you can do that, you can be socially successful with anyone. You think there are only a few women in the world who might like you because in the past you have been so unsuccessful. Your lack of success is because you have internalized well-meaning but false premises from contemporary culture. There is a vast abundance of women who are now, and will later be, made happy by “you being you” — the “you” that is charming, effusive, teasing, outcome-independent, and interaction-oriented, instead of restrained, deferential, passive, and overly polite. You will need to exercise these more outgoing parts of your personality so they can become strong. Get a copy of The Game by Neil Strauss to learn how, and go from there. It will jolt some of your prized sensibilities; they need to be jolted.

    “But what about programming?” you ask. Younger Me, you’re going to be good at that no matter what. It comes so easily to you. You don’t need advice there. Instead, put effort and practice into the things that do not come so easily to you. When you succeed at those, you will be more satisfied with your life as a whole, in addition to the satisfaction you will gain from your profession.

    With fondest hopes for our future,
    Older Me

     

    Thanks to Paul for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

    Recent dev.life Interviews

    leah_culver
    Leah Culver
    Peteris Krumins
    Peteris Krumins
    Eric Lippert
    Eric Lippert
    Chris
    Chris Hartjes

    by Gareth Wilson at April 27, 2015 03:19 PM

    April 26, 2015

    Dave Winer

    Great "Blue Sky" platforms

    The hairball

    Our current platform is a mess:

    1. CSS.

    2. HTML.

    3. JavaScript.

    4. A server.

    Think of how much you have to learn to become "full stack" in this world.

    At least four different syntaxes, and a CSS preprocessor.

    HTML is XML. JavaScript is like C or Pascal. The server could be written in any number of different languages. And JSON. None of them are going away.

    I've been working in this world for many years, and right now would be at a loss to write a canonical "hello world" app.

    What a Tower of Babel. What an opportunity to topple it, esp given all the people these days who want to program.

    It grows when it's simple

    The big strides in tech happen when the platform gets reduced to simplicity. Examples include:

    1. Unix with C.

    2. Apple II with UCSD P-System.

    3. MS-DOS with Turbo Pascal.

    4. The Web with a plain text editor.

    I call these blue sky platforms

    In all these systems, lifting the hood is child's play.

    Typing and modifying "Hello World" is easy. From there, there are no huge cliffs in the way of becoming a master.

    1995: "A platform must have potential, or open space. I call this blue sky."

    Digging out of the mess

    We can get back to blue sky any time we want.

    I would start from Node.js and build out.

    The web browser, as currently configured would have to be replaced by something that's thoughtfully designed. Or maybe a platform built on top of CSS+HTML+JavaScript, hiding it behind a factored interface? Not sure. But we'll never have great growth until we factor out the huge hairball sitting between ideas and implementation.

    April 26, 2015 04:49 PM

    April 25, 2015

    Dave Winer

    I would have hired Doug Engelbart

    I've heard it said, and thought myself, that of course I wouldn't have hired a 50-something developer when I was running my 20-something startup.

    But then I just realized that if Doug Engelbart had wanted to work for Living Videotext or UserLand I would have hired him in an instant. Can you imagine. To have the guy who pioneered the technology we were commercializing around to mentor me and my developers? I would have jumped at the opportunity.

    So the answer is, it depends. If it was a random employee type who hadn't done much with his or her career, I probably wouldn't have been very interested. But if it was someone who had created the foundation we were working on, that would have been different.

    Guy Kawasaki: "Good people hire people better than themselves."

    Update

    I wrote a follow-up to this piece on May 6.

    April 25, 2015 12:22 AM

    April 24, 2015

    Lambda the Ultimate

    Paul Hudak

    These are sad news indeed. I am sure almost everyone here read at least one paper by Paul and many knew him personally. When I just started thinking about programming languages I was fascinated by DSLs and his work was simply inspiring. His voice will be missed.

    Discussions of Paul Hudak's work

    Update:There is some confusion about the situation. Please see the comments for further information.

    April 24, 2015 12:26 PM

    Tim Ferriss

    Tim Ferriss

    [PLEASE NOTE: This competition has ended. Here are the winners. Thanks!]

    Unless you’ve been to outer space, the next few minutes are worth your time.

    Below are the details of The Zero-G Giveaway. My goal is simple: I want to you to have one of the coolest experiences on the planet. Namely, floating like an astronaut, experiencing weightlessness, and grinning ear-to-ear for a week afterward.

    I’m not selling anything and no purchase necessary. Just thought it’d be cool, and I have some big news coming next week, so this is a warm-up. I’m limbering up my Internet joints for action.

    All that said, you have less than 48 hours, so please keep reading.

    My approach to blogging is simple: share what excites me most. It doesn’t matter if it’s expensive, free, or really cheap (like this).

    Whether or not you win, I want to you to think of new possibilities.

    For the Zero-G giveaway, I teamed up with Huckberry because they offer so many things I love. Sometimes it feels like I’m shopping in my own closet.

    ACHTUNG! This is about getting people–a lot of people–excited. I want to you to dream big, and I want you to encourage others to do the same.

    That’s why the more you spread the word on social media, the more likely you are to win.

    If you want to enter, simply click here. It takes five seconds. After you sign up, you’ll be given the chance to spread the word to your friends. That’s it.

    I hope you enjoy these prizes as much as I do.

    Grand Prize (1 winner) 

    Second Prize (3 winners)

    If you’re not familiar with all the above prizes, here are few thoughts on why I chose to include them.

    Exo Protein Bars: These are the only bars I currently eat. Clean protein, paleo-friendly, no soy and made of crickets. The amino acid profile is killer, a former 3-Michelin star chef makes them delicious, and it’s minimally-processed compared to almost every other form of protein bar. No garbage, no fillers. CrossFitters and other athletes gobble these things up. Journalists have been surprised I eat these, as there is a bit of natural sugar, but they don’t spike glucose for me or media friends who’ve tested them.

    Soma: In its simplest form, it’s a high-end competitor to Brita water filters. It combines Apple-inspired design (sleek glass carafe) with a subscription service that delivers the world’s first compostable water filter to your door.  I have three at home.

    LSTN Headphones: So cool that they had to be included. These wood-rich headphones immediately get double takes, and they have everything you need—a microphone for calls and voice recording, and passive-noise isolation feature to highlight your tunes and keep out the rest of the world. These bad boys are consistently ranked as good or better than headphones 2-3x the price.

    In Conclusion

    Jump on it! The giveaway ends in less than 48 hours.

    To sign up, simply click here. And don’t forget: every time you share the page, your likelihood of winning increases.

    What else would you like to experience before you die? What’s on your personal bucket list?

    Good luck and pura vida :)

    by Tim Ferriss at April 24, 2015 02:45 AM

    April 23, 2015

    Mark Bernstein

    Badass: Making Users Awesome

    Badass

    is the logical culmination of the contemporary business book: a PowerPoint deck on paper. It’s a good deck; Sierra is first and foremost a speaker.

    Sierra’s insight here – and it’s a important – is that the whole point of technology marketing is to make users awesome, which means giving them tools to do great stuff, leading them toward using those tools well, and then getting out of the way. This is music to my ears, of course, since Tinderbox users are pretty much the definition of “badass” and “awesome” and each day’s Tinderbox support queue tends to be filled with a remarkable array of talented writers, journalists, scientists, and scholars. (Lots of musicians, too: I’m honestly not sure why.)

    One insightful example explores camera documentation. On the one hand, manufacturers tend to explain how to use this camera. But purchasers don’t care about that. They want to know how to take great pictures – better pictures than they could take with their old camera. That’s a useful framing for lots of technical marketing problems, and a very intriguing guide to improving sales, support, and training.

    The later sections of the book discuss strategies for help users become “badass” before they give up and abandon your product. Many of the strategies are heuristically sound, but Sierra presents them as necessary cognitive truths. This leads to an unfortunate rhetoric where we’re consistently cajoling or deceiving our user’s brain in order to help the user; instead of making users awesome, we’re manipulating them for their own good. Sierra embraces the weirdness heartily and underlines it on page after page with a series of brain icons – for example, a brain with a faucet symbolizes “distraction”.

    Actual cognitive arguments – arguments about how the brain actually accomplishes something – require more than intuitive plausibility and an experiment or two. We just don’t understand brains very well, they often work in ways that aren’t intuitively obvious, and it turns out that we’re not particularly good at thinking about our thinking. In a talk, this hand-waving might be more effective, but paper provides leisure to poke holes. In the end, we aren’t trying to solve the problem of the mind right now, we’re just trying to sell some stuff! The conclusion much of this reaches is the desirability of focusing training on skills and concepts that are immediately necessary and clearly rewarding; that conclusion doesn’t need any cognitive science at all.

    Nonetheless, the original observation is sound and significant. We aren’t playing silly psychological games to get customers to engage with the brand or to splurge on in-app purchases. We’re helping smart and capable people to do good and important work, one step at a time.

    April 23, 2015 08:10 PM

    Fog Creek

    The Effective Engineer – Interview with Edmond Lau

    .little {font-size: 75%}
    The Effective Engineer – Interview with Edmond Lau

    Looking for audio only? Listen on

    We’ve interviewed Edmond Lau, an Engineer who has worked for the likes of Google, Ooyala, Quora, and Quip and he wrote the book ’The Effective Engineer’. We discuss ways to maximize your impact as an engineer, lessons learned from engineering leaders, key metrics to measure your effectiveness as well as ways to onboard new hires.

    Content and Timings

    • Introduction (0:00)
    • About Edmond (0:21)
    • Lessons from Engineering Leaders (2:18)
    • Leverage and Feedback (3:30)
    • Onboarding New Engineers (7:24)
    • Balancing Technical Debt (8:35)
    • Common Engineer Career Mistakes (9:44)

    Transcript

    Introduction

    Derrick:
    Edmond Lau is a software engineer who has worked for the likes of Google, Ooyala, Quora and Quip. He speaks at conferences and writes on his blog about engineering best practices, and has recently authored the book “The Effective Engineer.”

    Edmond thank you so much for taking the time to join us today. Do you have a bit of information to share about yourself?

    About Edmond

    Edmond:
    I’m working at a startup right now called Quip. It builds up productivity suites. It’s optimized for teams, also optimized for mobile but for the past two years I’ve been working on the book that I recently released, “The Effective Engineer” which is a resource to help engineers basically be more effective and share a lot of stories from engineering leaders across Silicon Valley.

    Derrick:
    What made you want to write the book?

    Edmond:
    My first inspiration for writing the book came during my working Quora. Quora is a question and answer site, and during my time there the team grew a lot. One of my responsibilities at Quora was building the onboarding and mentoring program there. One of the things that I learned from the experience is that learning as an engineer, it’s pretty exponential. If you pick up the right habits and techniques and mindsets when you’re starting off, you’re significantly more likely to succeed and unfortunately sort of prior to having this onboarding program, it was sort of the luck of the draw whether you would have a good mentor, or whether someone would explain to you core concepts in your first day or your first week or your first month. People who got lucky were much more likely to succeed and much more likely to be effective many months down the line. The onboarding program was an attempt to level the playing field a little bit so that it wasn’t based on luck of the draw whether you had a good mentor, whether you were on-boarded well. The book is, it is actually sort of an extension of that onboarding work. There aren’t that many great books out there teaching engineers about mindsets of effectiveness. There are a lot of good books for entrepreneurs, a lot of books for business people, but not a lot of books that have stories from engineering teams and engineering leaders. It’s very focused… There’s a lot of lessons that teams, successful teams to day have learned. My writing the book is an attempt to provide a valuable resource that can help onboard engineers beyond just the companies that I work at.

    Lessons from Engineering Leaders

    Derrick:
    You spoke to a number of engineering leaders about the things that they had done to increase their impact. Were there any common themes?

    Edmond:
    I would say some of the most important ones I saw, one is focusing and investing in tooling. Especially teams like, when I talked with Bobby Johnson, who is former director of engineering for infrastructure at Facebook. Like I said one of the biggest time and investments that he made that had the one of the biggest ROI was just building tools. Trying to automated as much in mechanics of what they were doing as possible. Every time they got a problem they found that they were still repeating what they were doing. They would write a tool for it, automate it. That’s a very reoccurring theme that I found when I was talking to leaders at Twitter, Google, and sort of many other companies. Another pretty common theme is just keeping things simple. I think a lot of teams, when I asked them what’s the biggest lesson or the most valuable lesson you’ve learned in the past year, they would say they just sort of made things a little too complex. Things a little bit too long to maintain. There was a lot of operational burden to keep things going. Keeping things simple was sort of another very common theme.

    Leverage and Feedback

    Derrick:
    Part of your method as a framework called leverage, which helps engineers identify activities that have the most impact. Tell us a little bit more about how that works.

    Edmond:
    When it comes to leverage, leverage is something I cover in depth in the book but it basically means what is the output you’re producing for the amount of time you’re investing? It’s a metric of what is the impact you’re generating per amount of time that you spent and sort of as if your goal is to become an effective engineer, one of the key qualities is understanding what exactly leverage is. As an effective engineer you want to focus on the high leverage activities. This is something that took me many years to learn. First when I went to Ooyala after I left Google, I used to work 70 to 80 hour weeks because I thought that was how hard a team had to work as an underdog to succeed but there were a bunch of experiences where we built an analytics module to client and they never used it or we would build a product and it would never get the user adoption that we wanted. Or I would go on vacation and get paged because I was on call. Through all those experiences made me feel like working hard, putting in those hours just isn’t enough. The framework of leverage is taking the time to actually prioritize what are the things that are actually generating a large impact for the amount of time you’re spending. What are the activities that actually have a high ROI? If you don’t want to work 70, 80 hour weeks, the way that you can be effective is by focusing the limited amount of time you have on the activities that are actually generating the most impact.

    Derrick:
    How can engineers go about getting feedback to ensure what they’re working on is worthwhile?

    Edmond:
    The key there is, just setting up feedback loops and that sort of applies to everything you do. For instance, when you’re writing software that means you send around say a lightweight design doc to get feedback on your design before you even write a code. When you’re writing code it means if you want to optimize quality, optimize the feedback, you want to send your code to code reviewers that are the strictest. The ones who would critique, do a good job of critiquing what you’re doing. If you’re working on product it means getting feedback from decision makers of the company. Getting feedback from gatekeepers who sort of block or launch as soon as, as early as possible. Then when you’re sort of building or iterating a product, it means running like A/B tests to measure is this change actually materially improving the product in some way that you care about.

    Derrick:
    What are some key metrics that developers can use to ensure that they’re being impactful?

    Edmond:
    It really depends sort of which area, which team you’re working on. You want to pick a metric that incentivizes the type of behavior that you want. Just to give a few examples, like if you’re working on a performance team, you’re probably trying to improve some metrics. The metric that you want to improve, it could be something like 99th percentile of all load times. Or it could be the average load time. Both of those, either of those metrics would improve the performance of your product but they have very different outcomes. If you’re improving the average load times, that would tend to make you focus on general server improvements, but if you were focusing on the 99th percentile, which might be your power users or everyone who has a lot of data who sort of has worse experiences, then you’re focusing on the long tail of the application, what are the worst case instances that are happening? The choice of metric effects the type of work that you’ve focused on and so when you were … because of what product you’re working on you want to sort of pick the metric that is most aligned with success of the business. That might be focusing on weekly active rate instead of just focusing on future sign ups. Or it might be focusing on the 99th percentile versus the average page load time.

    Onboarding New Engineers

    Derrick:
    How should you onboard new engineers to ensure lessons like those you described are learned by all?

    Edmond:
    Onboarding is not something where you do it once and you’re done. It’s something you do very incrementally. I would say just start documenting questions that new engineers are asking and make them reusable resources. If you are a new engineer, then as you are onboarding identify what are the things that are giving me problems? What is taking a long time to do that really shouldn’t. Over time you sort of build up a repository of knowledge that becomes much more useful for new engineers joining the company. An example is at my current company, Quip, we make a productivity suite that’s really optimized for collaboration and so any time we are building new products we end up writing a short design doc that is then shared with the team or every time we come up with… It’d be great if our code looked like this. We write down the style guide and then everybody gets this new piece of information, or someone ran into an issue we document that into some best practices doc. We end up with lots and lots of documents that are really useful for new engineers.

    Balancing Technical Debt

    Derrick:
    A lot of engineering time gets lost addressing technical debt, how can you go about finding the right balance between maintaining the old while shipping the new?

    Edmond:
    It ultimately goes back to that framework of leverage that I mentioned earlier. Basically you don’t have enough time to basically focus on all of your debt. Your goal is not to refactor all your code all the time or to get to 100% test coverage or to do all your code reviews with the same level of quality. It’s really to just sort of focus on what is the debt that is causing the most pain? What are the problematic pieces of code that either get a lot of traffic from the product or that developers or engineers are focusing a lot of their time on. Those are the pieces where you want to spend the bulk of your time, writing unit tests, doing code reviews, refactoring code. Basically making all the core primitives, the core abstractions in your code really strong and reducing technical debt in those core areas because those areas will have the highest leverage in terms of making your team work much more effectively.

    Common Engineer Career Mistakes

    Derrick:
    What are some of the common mistakes you see engineers making who want to grow their careers?

    Edmond:
    A pretty common one is just they’re not optimizing for learning when they’re looking for job opportunities, and sort of being stuck on a plateau where they’re not really challenging themselves, they’re not really learning day to day. Just from my own experience, when I was at Google, it was a very comfortable place and sort of after, my first six months there I learned a ton. They have these documents called code labs that they teach about core abstractions and best practices. They give you exercises to validate that you understood everything. I learned a ton in my first six months there but after two years I felt like I wasn’t really challenging myself anymore, which is why I decided that maybe I should explore start ups and see if I might be able to learn more there. That mentality, just optimizing for learning and guided a lot of what I do. It’s taught me a lot of what I know today.

    Derrick:
    What resources can you recommend for those interested in learning to be more effective in their roles?

    Edmond:
    Even from my time of writing the book one of the most valuable things is just meeting up with other engineers, meeting up with engineering leaders and exchanging stories because when you’re working on the team, a lot of times the lessons we learn are just the ones that occur during the projects that you work on. People who have either had similar experiences or have gone through other projects, where sort of having conversations with them can teach you a ton.

    Derrick:
    Thank you for your time today.

    Edmond:
    Yeah, sure.

    by Gareth Wilson at April 23, 2015 10:15 AM

    Ian Bicking

    A Product Journal: As A Building Block

    I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

    I teeter between thinking big about PageShot and thinking small. The benefit of thinking small is: how can this tool provide value to people who wouldn’t know if it would provide any value? And: how do we get it done?

    Still I can’t help but thinking big too. The web gave us this incredible way to talk about how we experience the web: the URL. An incredible amount of stuff has been built on that, search and sharing and archiving and ways to draw people into content and let people skim. Indexes, summaries, APIs, and everyone gets to mint their own URLs and accept anyone else’s URLs, pointing to anything.

    But not everyone gets to mint URLs. Developers and site owners get to do that. If something doesn’t have a URL, you can’t point to it. And every URL is a pointer, a kind of promise that the site owner has to deliver on, and sometimes doesn’t choose to, or they lose interest.

    I want PageShot to give a capability to users, the ability to address anything, because PageShot captures the state of any page at a moment, not an address so someone else can try to recreate that page. The frozen page that PageShot saves is handy for things like capturing or highlighting parts of the page, which I think is the feature people will find attractive, but that’s just a subset of what you might want to do with a snapshot of web content. So I also hope it will be a building block. When you put content into PageShot, you will know it is well formed, you will know it is static and available, you can point to exact locations and recover those locations later. And all via a tool that is accessible to anyone, not just developers. I think there are neat things to be built on that. (And if you do too, I’d be interested in hearing about your thoughts.)

    by Ian Bicking at April 23, 2015 05:00 AM

    Dave Winer

    April 21, 2015

    Giles Bowkett

    Modulating The Arturia Minibrute With The Arturia Microbrute

    A 5-minute video explaining and demonstrating how to do it.



    I caught an awful flu earlier this year which had me incapable of doing anything other than sleeping or watching videos for two or three weeks. During that time I watched almost every Minibrute and Microbrute video on YouTube, and I was really surprised, because I did not find one video like this. I definitely saw some great videos, but nothing which addressed this fairly obvious use case. So I made this video.

    by Giles Bowkett (noreply@blogger.com) at April 21, 2015 09:14 PM

    Dave Winer

    My Apple Watch podcast

    I've made a dozen or more visits to the Apple Store website hoping to buy an Apple Watch and each time coming up empty and as confused as ever.

    This 12-minute podcast tells the story.

    BTW, here's a screen shot of the Apple website, referred to in the podcast.

    April 21, 2015 03:04 PM

    Fog Creek

    Better Agile and Sprint Planning with Iteration Planner

    Available today to all with Time Tracking in FogBugz On Demand is Iteration Planner. With Iteration Planner, we’re unlocking the power of FogBugz as an Agile planning tool for software development. By mapping sprints onto the FogBugz concept of milestones you can graphically group cases into the scope of work that you’ll complete in each sprint. You can also divide the scope of your sprint into groups of cases that make sense to your workflow. You can see how much work has been done toward each of the goals of your sprint. And additionally, you can balance the allocation of resources by dragging and dropping cases from one assignee to another. These features help to make the Iteration Planner a lightweight way to plan work and manage teams using FogBugz.

    Iteration Planner with two milestones created

    Key Features

    Drag and Drop to Update Milestones and Cases

    As you move objects around the Iteration Planner you’ll see that values for parameters like assignee, title, and estimates change in your FogBugz database. Cases and milestones created in the planner will appear throughout the rest of FogBugz.

    Drag and Drop

    Within FogBugz, Milestones are a flexible type of container

    Create milestones, for example, Backlog; Sprint x; and Doing; in order to customize the Iteration Planner for your workflow. Use the start and end dates for milestones to define your sprints.

    Add a milestone using this field

    Estimating cases and using Time Tracking

    This combination – case estimates and time tracking – allows you to see summaries of the estimated cases and hours spent on the tasks. Time Tracking in FogBugz tells you how much time you’ve spent on each case. If you’ve also estimated the cases that compose your sprint then the summary of hours shown in the Iteration Planner will be the estimated time remaining in the individual cases or on the milestone as an aggregate of the cases. This effectively tells you what portion of the estimated time remains. (*Note: the Iteration Planner requires Time Tracking.)

    You can plan iterations for each of your projects

    Iteration Planner allows you to see, search and manipulate cases and milestones within each of the projects in your FogBugz instance.

    ip-blogpost-pickproject_360

    Your search filters are available in the Iteration Planner search box

    These filters will allow you to find cases in the planner, in the same way that you find them in the rest of FogBugz. You can also simply enter a keyword in the search field to discover cases not listed in your filters.

    select through search filter

    Share Your Sprint

    The Iteration Planner is a unique view into your data. If you want to share that view with your colleagues, just copy and paste the URL as it appears when you’re looking at your organization of milestones and cases.

    Conclusion

    If you are running an Agile software development team, the Iteration Planner affords you a highly graphical tool for visualizing and manipulating the information you need for planning your sprints. With this tool, you’ll be able to set the direction for your team’s work and then monitor its progress toward accomplishing your organization’s business goals.

    Related Links

    by David Miller at April 21, 2015 02:23 PM

    Ian Bicking

    A Product Journal: What Are We Making?

    I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

    I’ve managed to mostly avoid talking about what we’re making here. Perhaps shyness, we (the PageShot team) don’t yet know where it’s going, or if we’ll manage to get this into Firefox.

    We are making a tool for sharing on the web. This tool creates a new kind of thing to share, it’s not a communication medium of any kind. We’re calling it PageShot, similar to a screenshot but with all the power we can add to it since web pages are much more understandable than pixels. (The things it makes we call a Shot.)

    The tool emphasizes sharing clips or highlights from pages. These can be screenshots (full or part of the screen) or text clippings. Along with those clips we keep an archival copy of the entire web page, preserving the full context of the page you were looking at and the origin of each clip. Generally we try to save as much information and context about the page as we can. We are trying to avoid choices, the burdensome effort to decide what you might want in the future. The more effort you put into using this tool, the more information or specificity you can add to your Shot, but we do what we can to save everything so you can sort it out later if you want.

    I mentioned earlier that I started this idea thinking about how to make use of frozen copies of the DOM. What we’re working on now looks much more like a screenshotting tool that happens to keep this copy of the page. This changed happened in part because of user research done at Mozilla around saving and sharing, where I became aware of just how prevalent screenshots had become to many people.

    The current (rough) state of the tool

    It’s not hard to understand the popularity of screenshots, specifically on mobile devices. iPhone users at least have mostly figured out screenshotting, functionality that remains somewhat obscure on desktop devices (and for the life of me I can’t get my Android device to make a screenshot). Also screenshots are the one thing that works across applications – even with an application that supports sharing, you don’t really know what’s going to be shared, but you know what the screenshot will contain. You can also share screenshots with confidence: the recipient won’t have to log in or sign up, they can read it on any device they want, once it has arrived they don’t need a network connection. Screenshots are a reliable tool. A lesson I try to regularly remind myself of: availability beats fidelity.

    In a similar vein we’ve seen the rise of the animated gif over the video (though video resurging now that it’s just a file again), and the smuggling in of long texts to Twitter via images.

    A lot of this material moves through communication mediums via links and metadata, but those links and metadata are generally under the control of site owners. It’s up to the site owner what someone sees when they click a link, it’s up to them what the metadata will suggest go into the image previous and description. PageShot gives that control to the person sharing, since each Shot is your link, your copy and your perspective.

    As of this moment (April 2015) our designs are still ahead of our implementation, so there’s not a lot to try out at this moment, but this is what we’re putting together.

    If you want to follow along, check out the repository.

    by Ian Bicking at April 21, 2015 05:00 AM

    April 20, 2015

    Dave Winer

    Should Boston bid on the Olympics?

    When I was chatting with Chris earlier today, the subject of the Olympics and Boston came up. Should Boston bid?

    My two cents

    Boston should not try to host the Olympics, in fact no one should. With climate change, a new venue for the Olympics every four years is an extravagance we can't afford. Sure it's a drop in the bucket but it's an important and symbolic drop in the bucket.

    Build one great Olympic facility, designed to be usable for 100 years. Hold all future Olympics there.

    It's like the United Nations. We don't build a new skyscraper every four years. We built one really good one, and use it every time we need the UN.

    April 20, 2015 10:04 PM

    Mark Bernstein

    Dashboard

    My imaginary thriller proceeds, and with it I’m building some Tinderbox infrastructure to keep an eye on how the trip is shaping up.

    Dashboard

    The raw character map is easy enough to put together in any diagramming program, but here we’re using Tinderbox agents and rules to keep a running total of our expenses as we add them. Tinderbox is also handling currency conversions; these expenses are entered variously in dollars, euros, pounds sterling, and Swiss francs.

    You could do this in a spreadsheet, sure, but where in the spreadsheet are you going to put your character notes, much less our internal memos?

    Meanwhile, we’ve gone from Paris to Dijon, on to Zürich, down to Torino, and now we’ve dashed off to London for the weekend conference of our (fictitious) open source competitors. It’s nice to be spending an imaginary company’s notional revenues!

    April 20, 2015 09:03 PM

    Wonderland

    The story of a rock-and-roll comeback, nicely written and filled with convincing detail. D’Erasmo does a masterful job of using small asides to good effect and has a nice feel for quickly sketching distinct places in the midst of a band tour where we’re constantly moving to a new city. What really works here is the world building: Anna Brundage is a convincing minor star and D’Erasmo does a terrific job of sketching the contours of a career, the small triumph of the first-album Whale, the disastrous Bang Bang tour – as well as a performance gone wrong in Hamburg, a rained-out music festival in Latvia, and the crucial distinction between flings with men you’ve scarcely met (which, on tour, is basically everyone you could possibly have a fling with) and sleeping with fans (which, on tour, is pathetic).

    Before setting off on this last best chance, the Wonderland tour, Anna had been teaching shop at a private school in Manhattan; whenever failure looms, it manifests as the specter of a hundred little girls with hammers.

    April 20, 2015 06:58 PM

    Tim Ferriss

    TF-StitcherButton

    Triple_H_pic
    “His way of telling you that you did something wrong was hitting you in the head with a phone book in a shopping bag.”
    – Triple H (Paul Levesque) on learning from Killer Kowalski [10:05]

    “Why would I be wound up? I’m either ready, or I’m not. Worrying about it right now ain’t gonna change a damn thing.” 
     Floyd Mayweather, Jr. just before a fight, as recalled by Paul Levesque [34:20]

    Paul Levesque, more popularly known as Triple H (@TripleH), is a 13-time World Heavyweight Champion in World Wrestling Entertainment, Inc. (WWE). Not only that, he is also the Executive Vice President of talent, live-events, and creative at the WWE.

    In this episode we explore everything, including the teachings of Killer Kowalski, how he avoids and repairs injuries (even if on the road 200+ days of the year), pre-game rituals, and habits developed with the support of trainer Joe DeFranco, The Undertaker, and even boxer Floyd Mayweather, Jr..

    This podcast is not limited to athletic performance. We dig deep into Triple H’s inspirations, and how he manages his responsibilities as a husband and father of three daughters.

    [Also, if you missed it, I’m giving away a once-in-a-lifetime zero-gravity flight! If you’ve ever wanted to float like a astronaut, this is your chance. Click here for details.]

    Enjoy!

    TF-ItunesButtonTF-StitcherButton

    Have you heard my previous blockbuster episode with Tony Robbins? — Triple H listened to this episode while preparing for our interview. In my episode with Tony, he shares his bizarre morning rituals, thoughts on punching Barack Obama, and how to master the game of money (stream below or download by right-clicking here for part 1 and right-clicking here for part 2):


    This podcast is sponsored by LSTN Headphones. LSTN Headphones are gorgeous headphones made of real exotic, reclaimed wood. Proceeds from each purchase help a hearing-impaired person hear for the first time through the Starkey Hearing Foundation. Check out the headphones that I love and travel with here: LSTNHeadphones.com/Tim. On that page, use the code “TIM” to get $50 off orders of $99 or more!

    This podcast is also brought to you by 99Designs, the world’s largest marketplace of graphic designers. Did you know I used 99Designs to rapid prototype the cover for The 4-Hour Body? Here are some of the impressive results.  Click this link and get a free $99 upgrade.  Special offer: For the month of April only, you can get an additional $30 off. Give it a test run and share your results!

    QUESTION(S) OF THE DAY: What’s the best advice you’ve ever received for injury prevention or repair? Please share (or read) in the comments.

    Scroll below for links and show notes…

    Enjoy!

    Selected Links from the Episode

    Show Notes

    • How Paul Levesque answers the question, “What do you do?” [05:10]
    • Common misconceptions of Triple H and the WWE [6:30]
    • Important lessons learned while training with Killer Kowalski [9:40]
    • Emotional story telling: the critical factor behind each WWE event [12:45]
    • Why a regimented daily workout schedule is critical for longevity as an athlete [16:25]
    • Training as mediation [21:55]
    • Pre-game rituals with the help of Joe DeFranco, The Undertaker, and Floyd Mayweather [23:05]
    • Learn about Triple H’s models of success [35:10]
    • Insights on fatherhood [40:55]
    • Describing the first 60-90 minutes of every day [43:25]
    • Triple H’s current role in the WWE and his responsibilities as Executive Vice President [47:45]
    • Rapid fire questions:
    1. Most played band/song [52:39]
    2. If you could only do 1 or 2 exercise movements for the rest of your life what would they be? [53:00]
    3. Advice for your 20-year old self [53:40]
    • The story of meeting Tony Robbins [55:15]

    People Mentioned

    by Ian Robinson at April 20, 2015 06:36 PM

    Dave Winer

    5-minute podcast

    I was talking with Chris Lydon about the idea of a 5-minute podcast.

    Then Doc Searls asked a question that I thought could easily be answered in 5.

    I was right, but I rambled too much and it turned into a 6.5-minute podcast.

    Next time we'll do better!

    April 20, 2015 05:04 PM

    The open tech of Podcatch.com

    On Friday, as you may know, I made Podcatch.com public.

    It's a quick way to find a great podcast to listen to, now. Without subscribing.

    The list of feeds is curated, it originated from the feeds my Facebook friends liked the most. In that I think it's a prototype for how social networks can be used to create new flows that aren't complicated or hard to use or appreciate. I think, btw, this is the holy grail Twitter has been looking for.

    The JavaScript environment

    What I haven't talked about yet is all the great open technology it builds on. Stuff that's available to anyone to use to create new apps. One of the amazing things about developing in JavaScript in 2015, and hasn't been well-appreciated yet, is how deep and generous the developer community is, to itself. I've never seen anything like this.

    Technologies we use

    So here's a partial list of technologies I'm using to make this work, all of which are open source and available to all, free of charge and on equal terms.

    1. Font-Awesome for the icons.

    2. Bootstrap Toolkit for the CSS framework.

    3. jQuery to make access to the DOM uniform across browsers.

    4. snap.js manages the sidebar in the app (new feature today).

    5. River4, manages subscriptions, river generation and browsing.

    6. Feedparser does all the feed parsing for River4.

    7. OPMLparser reads the subscription lists for River4.

    8. RSS is what podcasting is built on, of course.

    9. Node.js runs the custom back-end Podcatch software and River4.

    10. NPM supports the building of the backend bits.

    11. V8 which is the JavaScript interpreter in Node.js.

    12. HTML5 has an <audio> element we use to play the podcasts.

    13. Google Fonts for Oswald and Ubuntu.

    Thanks!

    Thanks to all the generous developers (with a caveat that I am thanking myself for River4 and RSS, I know it's weird).

    I'm sure this list will grow as I remember more bits of generosity that I'm building on.

    This tech makes people rich

    BTW, one of the reasons I listed the open tech that podcatch.com builds on is to increase the visibility of these essential components.

    For entrepreneurs and VCs who have made billions from tech, you should know that this would not be possible without the generous work of people who mostly do it for love, with no expected remuneration.

    If you think you support open tech and are not actively supporting this work, you're not. Sometimes you have to tell truth to power. This is one of the truths that has not been well-told.

    April 20, 2015 01:56 PM

    The new WTC elevator

    One of the things I love about NYC history is the layering and the continuity. It's how I think software should evolve too. We rip up our software cities too easily, because we don't like the arrangement of the streets, forgetting that there are real people living and working in our cities.

    So I totally got off on the elevator movie that takes you to the 102nd floor observation deck in the new WTC tower. It shows you how the city evolved from nothing to a small Dutch settlement at the tip of Manhattan (south of the WTC site) to the huge metropolis it is today. You even get a look, briefly, at the ill-fated tower that came down on 9/11.

    But there are mistakes, as has been observed, and one howler that as far as I know has not been reported yet. Here's the problem. They show the Brooklyn Bridge, clearly, in 1825. But it wasn't finished until 1883.

    April 20, 2015 01:28 PM

    Fog Creek

    dev.life – Interview with Chris Hartjes

    In dev.life, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

    Today’s guest is Chris Hartjes, Senior Developer at Roave. He is the organizer of the TrueNorthPHP conference and co-presenter of the /dev/hell podcast. Although he is perhaps best known in his more curmudgeonous form, as the author of the ‘Grumpy Programmer’ series of books and screencasts, including ‘The Grumpy Little Book Of Hack‘ and ‘The Grumpy Programmer’s PHPUnit Cookbook‘.


    Chris Hartjes
    Location: Milton, Ontario, Canada
    Current Role: Senior Developer at Roave

    How did you get into software development?

    My first computer was a Commodore VIC-20 when I was 11 or 12 years old (1982-1983). I started off with Commodore BASIC. I spent many, MANY hours typing in programs from the old Compute magazine and wondering how they could make that Centipede clone I would play endlessly, fit into 5k of memory. My sister and I would take turns typing stuff in, switching every time we had to turn the page in the magazine.

    So I’m mostly self-taught. I took Computer Science at a Community College, but this was pre-web. I still remember the first time I browsed the web with Mosaic. It blew my mind after having spent a good 6 months surfing the web text-only using Lynx. I was hooked forever.

    My first “professional” programming job was when I was asked to build a website for the company I was doing IT support for. “We need something free? What’s this PHP thing I found via AltaVista…”. I was a late arrival to programming as a career. I originally went to college for Civil Engineering but went back to school for Computer Science in 1994 after spending a summer spending 60 hour weeks working for very little money on job sites testing asphalt and soil for proper compactness.

    vic20

    Tell us a little about your current role

    I work 4 days a week with the team at Roave, which I think can best be described as a programming co-op with a focus on projects that use PHP. I currently work with a client who sends out high volumes of SMS and voice broadcast messages every day. The other one day of the week, I work on my burgeoning info-product empire consisting of books and screencasts. I also spend a lot of time on Twitter both promoting good code testing practices and doing performance art.

    I currently act as a Senior Developer for one of the two programming teams for the message systems client. A typical day is going over the tasks assigned to me and figuring out how to solve the problems I’m faced with. I get a lot of freedom to choose what to work on, so I tend to pick tasks that are of the clean-up variety. Fixing code that is spewing warnings all the time into the error logs, reworking tests so that we are not reliant on a flaky development database server, things like that. I’m not sure what that says about me. A lot of what I’m asked to do these days involves changing the direction of developer workflow and culture. I spent several months using automated tools to update and test a PHP code base being upgraded to be PSR-2 compliant. I also spend a lot of time looking at ways to change how the existing tests are being written so we have a more useful test suite as the team moves towards continuous integration practices.

    I have been one of the loudest voices in the PHP community advocating for writing testable code and adding automated testing to your development process. I used to speak at a lot of conferences, but I’ve scaled back the travel in the last year or so. Speaking at conferences is something I really enjoy and I have worked very hard to get good at public speaking. By rough estimate, I have given about 50 talks since 2006 between physical conferences, virtual conferences, and user groups.

    I also help organize Canada’s only PHP-centric developer conference called TrueNorthPHP, held the first weekend in November at Microsoft’s Canada HQ, just West of the airport in Toronto.

    These are all things I am passionate about so it never gets old.

    When are you at your happiest whilst coding?

    After more than 17 years of being paid to do this type of work, I’m happiest when I’ve solved a problem to my satisfaction. Sometimes the people asking me to solve the problem are satisfied too.

    hjkl_keyboard

    What is your dev environment?

    I use OS X on a MacBook Air, running Yosemite. I’m a Vim user and currently use about ~20 plugins. I would say the ones that I cannot live without are:

    • supertab
    • syntastic
    • vim-surround
    • vim-gitgutter

    The rest are ones that drift in and out of my use depending on what sort of things I happen to be working on at the time. I’m a big believer in picking an editor and learning it inside out. HJKL for life!

    I prefer to do my development work using Vagrant-powered virtual machines, but that’s not always possible. Learning to be proficient with Vim has made editing code on remote servers a non-issue.

    Other programs I use all the time are:

    • Chrome / Firefox / Safari — always have to check if stuff is working in all three at various times
    • Skype – I do my podcast /dev/hell with my buddy Ed Finkler using AudioHijack Pro and Skype
    • IRC clients – I spend all time in IRC and one of my hobbies consists of playing simulation baseball with others over IRC
    • Tweetbot
    • iTerm

    I code sitting – Last year I bought a Herman Miller Aeron chair. Why did I wait so long?!? As a large human (I’m 6’5″, 265lbs) I have a hard time finding furniture that I can use comfortably. That and clothes. And shoes. I listen to music off and on depending on my mood. My only coding quirk is being annoyed when there aren’t tests for the code I’m working with. I will write them if I can.

    What are your favorite books about development?

    I don’t read as many programming books as I used to, but there are two books that had a profound impact on me and my career:

    • The Pragmatic Programmer‘ introduced me to many ideas and concepts that have served me well throughout the years. I read it at least once a year to help keep me focussed on being the best programmer I can.
    • Extreme Programming Explained‘ introduced me to unit testing at a time in 2003 when I had been working on a project that had been a complete disaster when it launched. Unit testing seemed to be something that would’ve prevented a lot of the problems we faced.

    What technologies are you currently trying out?

    Having worked with dynamically-typed scripting languages, like PHP, my entire professional career, I would love to work with Go or Rust. Compiled languages are something I only ever used at College.

    WhatIsMagic

    When not coding, what do you like to do?

    I am a long-time simulation baseball player (18 years and counting in the same league) and I also supremely frustrate myself playing the collectable card game ‘Magic: The Gathering‘.

    Working from home has made a huge difference to my family life. My wife and two kids seem to be happy that I am always around. 9 years ago I made the switch to working remotely full-time and have never regretted it.

    What advice would you give to a younger version of yourself starting out in development?

    Haters are gonna hate so just keep doing your thing.

     

    Thanks to Chris for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

    Recent dev.life Interviews

    phil_sturgeon
    Phil Sturgeon
    leah_culver
    Leah Culver
    Peteris Krumins
    Peteris Krumins
    Eric Lippert
    Eric Lippert

    by Gareth Wilson at April 20, 2015 10:05 AM

    John Udell

    Online identity: Where collaboration and innovation get stuck

    Before I was hired by Hypothesis, a nonprofit that's building a Web discussion platform, the team used Trello for project management. Then it switched to HuBoard, one of a number of tools that layer project management features on top of GitHub.

    When I joined three weeks ago, however, nobody at Hypothesis was happy with HuBoard, and there was nostalgia for Trello. So that's what I'm using now to manage the development of our product.

    [ See what hardware, software, development tools, and cloud services came out on top in the InfoWorld 2015 Technology of the Year Awards. | Download the entire list of winners in the handy Technology of the Year PDF. | Cut to the key news in tech with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]

    The crux of the issue for our team is that a wrapper around GitHub won't do the trick. We need to operate at a higher level of abstraction. We're an open source project, and GitHub is at the core of what we do. But we're now expanding from a small team of engineers to a larger team that includes three new program managers.

    To read this article in full or to leave a comment, please click here

    by Jon Udell at April 20, 2015 10:00 AM

    April 19, 2015

    Giles Bowkett

    Arx: Clojure (Overtone) Archaeopteryx Port

    I've finally open-sourced an Archaeopteryx rewrite in Clojure using Overtone. It's called Arx. I wrote this last year but only just open-sourced it today. I had planned to make the code more idiomatic, and upgrade the drum samples, but I forgot all about it, so I figured I should just get on with it.

    I also wrote a similar Clojure project in 2013 at WACM. It's called markov-bass-lines and it builds moombahton beats with a very entry-level Markov chain.

    by Giles Bowkett (noreply@blogger.com) at April 19, 2015 05:47 PM

    Mark Bernstein

    Too Many Books?

    Tim Parks:

    At present, for example, it’s hard not to feel that we are in an era of massive overproduction. Just when we were already overwhelmed with paper books, often setting them aside after only a few pages in anxious search of something more satisfying, along came the Internet and the e-book so that, wonderfully, we now have access to hundreds of thousands of contemporary novels and poems.

    Note to the copy editor of the NY Review of Books:

    True, in the early 1300s, with the establishment of the first partially mechanized paper mills in Italy, a more generous supply of paper began to circulate and the number of people able to write rapidly increased.

    Did the number of writers increase rapidly? Or does the increase relate to how many people could write hurriedly, swiftly, and in a rush?

    April 19, 2015 04:23 PM

    Dave Winer

    T-Mobile travails

    I was taking an early morning walk in Manhattan this morning when the fourth wall popped with T-Mobile. I was dropped out of The Matrix and smack in the mire of post-millennial mobile access.

    My recently-upgraded T-Mobile account was missing a vital feature. I found out about it just as I was getting ready to use a service that requires a net connection.

    The 20-minute story in a podcast.

    April 19, 2015 03:10 PM

    April 18, 2015

    Mark Bernstein

    Planning A Conspiracy

    I’m toying with an odd fiction project that, if all goes well, will generate some useful background material for Tinderbox 6.3 while perhaps being interesting (or amusing) for its own sake.

    It’s going to be a quick and dirty thriller. To get things rolling, I need to lay down the bones of the conspiracy our protagonist will eventually discover, a conspiracy that’s going to ruin her April. That means keeping the players straight.

    Planning A Conspiracy

    Nothing very profound here; it's just a quick sketch. Usually, I just keep a list of the characters in outline view for fast reference, but here we’ve got to manage all sorts of shadowy and undisclosed relationships (and at least one double agent).

    Green people work for us; light green people are contractors. Red people work, perhaps indirectly, for the bad guys; at this point, I know less about the Opposition than I do about our hero. That’s one reason for this exercise.

    Of course, lots of brainstorming, “mind mapping,” or diagramming tools could do this well enough. What’s nice here is that we can seamlessly extend this to add background to characters, change their associates, perhaps use some rules to keep all this organized.

    April 18, 2015 04:49 PM

    April 17, 2015

    Mark Bernstein

    Tinderbox 6.2

    Tinderbox 6.2

    Tinderbox 6.2 is now out.

    So what I particularly like is that, even as a trivial user, things are just getting better and better.— E. P.James, Tinderbox Forum

    April 17, 2015 05:04 PM

    Dave Winer

    The future of journalism

    There's a future-of-journalism conference in Austin. I'd like to insert a recipe, if I can, for the future of journalism.

    1. Start by solving problems. In all likelihood the geography you serve (if you are geography-based) has awful Internet connectivity. Before doing anything else, you must take ownership of that problem. If your readers have lousy Internet they will not be full participants in the world-wide news system. NYT, NYP, NYDN take note please.

    2. Work on your collective rolodex. That is the definition of who you are. The better it is the better you are. I'd be surprised if many current news orgs see it that way. But they will. (By the way you can start on this step before the previous step is complete. It might take years, even decades.)

    3. Make sure you have in your rolodex a field called "Feed" and in that field include the address of your source's RSS (or Atom I don't care) feed. You're going to need it in step 4.

    4. Make a river out of those feeds. Start watching that river. Tell your sources about the river, give them the address. About five minutes after that you will be jumping up and down with excitement. Five minutes after that it will be on your home page.

    5. Congratulations, you now have a future.

    April 17, 2015 04:24 PM

    Introducing Podcatch.com

    I was bored with my podcasts. I subscribed to a dozen different feeds, but was only listening to two shows. Sometimes I'd leave the house with nothing interesting on my phone. I muddled along, thinking this was the best I could do. Then came Serial, and all of sudden podcasting was exciting again. I looked forward to every week's installment the same way I look forward to a weekly Game of Thrones or Mad Men.

    A fog of podcasts

    What followed was an explosion of new podcasts, or so it seemed, but which were the good ones? I did what everyone does, I asked my friends. I saw my friends asking. I asked again. Sometimes I found something interesting to listen to, but usually not something I wanted to subscribe to. That got me thinking.

    Subscribing may be the wrong way to look at it. When I want a podcast I don't want to subscribe. I want to listen. All the time between the want and the fulfillment seems like work. Why is this so hard.

    I tried an experiment

    Standing on the street in Manhattan, with my iPhone 6 and a good net connection, how long would it take me to find something to listen to.

    In other words, how long after having the idea "I want a podcast" did it take to fulfill it. Standing out there in the cold. Feeling like an idiot, fussing with my phone.

    How long? A lot longer than it should.

    An idea from Vox

    Then I read an article in Vox that listed 26 podcasts I should be listening to. There's the answer. Almost. If they had a page that followed all these podcasts, I could go there, click a play button and be listening in an instant. Someone with good judgement chose these shows, and I bet one or two of them are good in any week. But that place didn't exist.

    Another experiment

    I asked my friends on Facebook to recommend their favorite podcasts. I figured if we were friends, or friends-of-friends, some of our interests would overlap. But I did more than ask, I engaged. And I didn't ask for feeds, I was willing to do the research to go from the title of the podcast to the RSS feed.

    I set up a river, customized it so there was a player for each item, and linked it up with Facebook comments, so the resulting conversations would feed back into my relationships.

    The product

    As Apple says about their products, it has magic. It's simple, it's probably not what you expect, but it really works. When I go there, I find new ideas, feelings, perspectives, entertainment.

    That's Podcatch.com.

    And now it's public. You can use it too!

    A picture of a slice of cheese cake.

    April 17, 2015 01:02 PM

    How to Node

    Node.js For Beginners. Deploy Your Blog to Heroku

    Error pages are not what typically appear on your screen when you're surfing the web, but when it happens it's so annoying! To see how servers work from within, we will build a simple web server by ourselves. We will use Node.js as a server part technology for that task. Then we'll use Heroku cloud application platform to turn this local server into a world wide server.

    Why should I?

    Hi, everyone! Don't know how about you, but my weekend was great!

    Friday evening. I came home from work, fed my cat, grabbed some pizza, and wanted to have some fun. What could be funnier than good old movies? Nothing, right? So, I went to "IMDB Top 500" to choose one. Then this happened:

    IMDB is down

    And I had to choose my evening movie randomly. It was "Sharknado". Should I say that my Friday was ruined?

    To be honest, this is not what typically happens when you are surfing the web. But when it does... Man, it's so annoying! It's annoying, but we're curious, aren't we? And, for our curiosity to be satisfied, we will build a simple web server by ourselves. It will help us to see how it works (or how it won’t work) from within.


    How can I?

    We will use Node.js for our project. Node.js is an open source, cross-platform runtime environment, which allows you to build server-side and networking applications. It's written in JavaScript and can be run within the Node.js runtime on any platform. First of all, of course, you need to install it. You'd better check the download page for more details. I'll wait until you finish, so don't worry. Is it done? Great! Now you can create your first web server. And it will be one of the easiest tasks in your life.

    Pretty simple, but it's a server!

    First of all, we need to create a JavaScript file. Let's name it server.js:

    server.js>

    It's simple. It's tiny. But it's a server! Let's make sure it's working. Run at your terminal:

    node server.js
    

    Then check it in your browser. Your new server's address, as you may guess, is http://localhost:3000/ Mine is working. How about yours? Hope, it's working too.

    localhost server

    Now, to be sure it's a web server and not just a piece of code that returns a single line of text, we'll use it as a server! You can check it with your smartphone. Let's suppose, your laptop's IP address within your local network is 192.168.1.101. You can connect to your server through the 3000th port (for this particular example) by typing http://192.168.1.101:3000/ in your browser. Works well in my case:

    Server via smartphone

    Well, it is a server! And we have evidence. What you got here is your own client-server model, which can fit in your bag! Take it any place you want! It will be a good idea to deploy our server online, so everyone could see it.

    But you should notice something, before we go further. Let's look more closely at our first Node server. This is an example of how Node provides you with non-blocking and event-driven behavior. Let me explain:

    $.post('/some_requested_resource', function(data) {
      console.log(data);
    });
    

    This code performs a request for some resource. When the response comes back, an anonymous function is called. It contains the argument data, which is the data received from that request.

    So, Node allows you to use the so-called event loop, which works faster because of non-blocking behavior. For example, nginx uses an event loop with asynchronous I/O. That's why it's fast as hell!

    This is not so hard to understand this conception in outline, so let's move along.

    Make it worldwide

    Works fine. But it works locally. WWW is for "World Wide Web" and we will turn your local server into a world wide server. We'll use Heroku cloud application platform for this. Heroku is a cloud platform as a service (cool long-bearded programmer guys call such type of things "PaaS"). It allows you to deploy your web server, so everyone could see how awesome you are as a web developer. First of all, you need to create an account on developer's site and install Heroku. This is not so hard. Just follow the instructions. There is also instruction on Heroku's site that can explain you how to run your first simple web server, which returns you the "Hello, World!" string. You can try it, but I think that it will be more interesting if we build our own web server from scratch. Sounds exciting, huh?

    Look, mom! I'm developing!

    First step after Heroku installation is to log in to the system from your computer:

    heroku login
    

    We will leave Heroku for now. But we'll need it soon after we build our server.

    Now, the creation. It will be a simple blog with basic functionality. It will show you requested web pages and the error page in case of an error.

    Create your project directory. And then create the server.js file inside of it.

    First of all, let's declare some variables:

    var http = require("http");
    var fs = require("fs");
    var path = require("path");
    var mime = require("mime");
    

    The first one will give you the key to Node's HTTP functionality. The second one is for possibility to interact with the file system. The third one allows you to handle file paths. The last one allows you to determine a file's MIME-type. And it's not a part of Node.js, so we need to install third-party dependencies before using it. We need to create the package.json file for that purpose. It will contain project related information, such as name, version, description, and so on. For our project we will use MIME-types recognition, because it's not enough to just send the contents of a file when you use HTTP. You also need to set the Content-Type header with proper MIME-type. That's why we need this plug-in.

    Create the package.json file and fill it with proper information. Here's mine:

    package.json>

    There are "name", "version", "description", and "dependencies" fields in it. The syntax is simple, as you can see. We added our "mime" plug-in and now it's time to download it. We'll use built-in Node Package Manager. Just run:

    npm install
    

    It will create node_modules folder and place all the files inside of it. So, we resolve our dependencies and can return to our code.

    We will now create send404() function. It will handle the sending of 404 error, which usually appears when requested file doesn't exist:

    function send404(response) {
      response.writeHead(404, {"Content-type" : "text/plain"});
      response.write("Error 404: resource not found");
      response.end();
    }
    

    Nothing sophisticated with this one. It returns plain text when server can't find a page.

    Now we will define sendPage() function. It first writes the header and then sends the contents of the file:

    function sendPage(response, filePath, fileContents) {
      response.writeHead(200, {"Content-type" : mime.lookup(path.basename(filePath))});
      response.end(fileContents);
    }
    

    Notice the way we handle the MIME-types.

    Now we'll define how our server will handle responses. This function will return the content of the requested file or the 404 error otherwise:

    handler.js>

    And now it's time to create the HTTP server:

    create-server.js>

    Now we need to start our server. And here's the tricky part. Do you remember how we told the server to listen to the 3000th port in our first example? No? I'll remind you:

    http.createServer(<some code here>).listen(3000)
    

    We can do it when we run our server locally. But Heroku sets a dynamically assigned port number to your app. That's why we need to handle all this mess with ports as it’s shown below:

    var port_number = server.listen(process.env.PORT || 3000);
    

    You can use the port_number variable later. For example, in console.log() function to tell the user, which port is used. This is your homework for tomorrow.

    That's all we need to run our simple web server. Now it's time to create some content. We'll create the public folder and two folders inside of it: stylesheets and images. We'll put all our HTML files into the public folder.The stylesheets folder is for CSS files. And the images one is for pictures.

    We need to create the index.html file. It will determine our blog's exterior. Here's the code:

    index.html>

    Here you can see how the main page looks like:

    My simple blog

    You are free to create your own CSS file if you don't like our design.

    What we are interested in for now is how our server handles the 404 error. That's why we created two "Read more" links. The first one is connected with the actual HTML file within the public folder. The second one is broken. Let's test how it works.

    To start your server locally run:

    node server.js
    

    And then click the first link:

    It works

    Then return to the main page and check the second one:

    enter image description here

    Here's our 404 page.

    We tested our simple server locally and now is time to deploy it.

    It's Heroku time!

    Open your terminal within your project folder. For my Linux it's:

    cd /path/to/my/project
    

    Then run:

    git init
    

    Empty Git repository will be initialized in .git/ folder.

    Then run:

    git add .
    

    This command allows Git to track your files changes.

    Now commit your files to the initialized Git repo:

    git commit -m "Simple server functionality added"
    

    We'll create our first Heroku application now:

    heroku create
    

    Heroku will generate a random name for your application. In my case it's enigmatic-citadel-9298. Don't worry. You can change it later.

    Now we can deploy our project. Every Heroku app starts with no branches and no code. So, the first time we deploy our project, we need to specify a remote branch to push to:

    git push heroku master
    

    The application is now deployed. Ensure that at least one instance of the app is running:

    heroku ps:scale web=1
    

    And now, before we open it, it's time to choose a proper name for our first creation. I called it myfirstserver:

    heroku apps:rename myfirstserver
    

    Everything is done. You can try it now:

    heroku open
    

    This command will open your Heroku project in your web browser. In this particular case, server address is https://myfirstserver.herokuapp.com/. Now you can share your first web application with any person you want.

    Looking back

    We've built our own web server using less than 50 lines of code. Not so hard, if you ask me. It's pretty simple, yes. But you can see, how average server works. It was a simple task. But you can combine Node.js with different technologies, such as CSS3 and HTML5, then spice it with some JavaScript functionality. There is really a lot of libraries and frameworks to take a look at. Personally I started to dig into Webix, it's a relatively new library and is developed by a small software company from Eastern Europe. Samples of apps made with the library and Node.js: CRM and task planner. Seems like you can create anything with the right client-side framework and Node.js.

    And, talking about Node.js as a technology...

    ...it will make your DIRTy job for you.

    There is an acronym created to describe such type of applications Node.js was created for. It's DIRT. It means Data-Intensive Real-Time applications. Node allows a server to handle a lot of connections and work with a number of requests at the same time. And you don't need much memory for that. It's designed to be responsive and fast. Just like your web browser! So, it's useful when you need to create an application that will be able to respond instantly to a large number of users. And Node was built from scratch to provide you with such a functionality.

    Well, that's enough for today. Hope you liked it. See ya!

    by dhx.products@gmail.com (Lenny Witman) at April 17, 2015 10:53 AM

    Fog Creek

    Using Forensic Psychology to Spot Problems in Your Code – Interview with Adam Tornhill

    .little {font-size: 75%}
    Using Forensic Psychology to Fix Software Development – Interview with Adam Tornhill

    Looking for audio only? Listen on

    We interviewed Adam Tornhill, a software architect who combines degrees in Engineering and Psychology to get a different perspective on software. We discuss his book ‘Your Code as a Crime Scene‘, in which he describes using Forensic Psychology techniques to identify high-risk code, defects and bad design. He describes how his techniques are useful by themselves, but can also be used to make other practices like code reviews and unit testing even more effective.

    Adam’s Code Maat software is on GitHub.

    Content and Timings

    • Introduction (0:00)
    • About Adam (0:31)
    • Detecting Problem Code (1:43)
    • Improving the Software Architecture (3:00)
    • Social Biases and Working in Groups (4:02)
    • Working with Unit Testing and Code Reviews (7:20)
    • Tools and Resources (8:32)

    Transcript

    Introduction

    Derrick:
    Adam Tornhill is a Programmer and Software Architect who combines degrees in engineering and psychology to get a different perspective on software. He’s the author of “Lisp for the Web”, “Patterns in C”, as well as “Your Code as a Crime Scene”, in which he describes using forensic techniques to identify defects and bad design in code.

    Adam, thank you so much for taking the time to join us today. I really look forward to hearing what you have to say. Why don’t you say a bit about yourself?

    About Adam

    Adam:
    Oh yeah, sure. It’s a pleasure to be here. I’m Adam Tornhill and I’m from Sweden, which is why I have this wonderful accent. I’ve been a programmer for a long time. I’ve been doing this for almost two decades now, and I still love what I do.

    Derrick:
    I wanted to touch on one of your books, “Your Code as a Crime Scene” where you apply forensic psychology techniques to software development. What made you think to apply techniques from what would seem to be such an unrelated field?

    Complexity metrics, the old kind, they just didn’t cut it

    Adam:
    It actually came a bit surprising to me as well. What happened was some years ago I was in the middle of my psychology studies, working towards my master’s degree and then got hired into architectural roles where I had to prioritize technical debt and identify problematic areas. I found that it was terribly hard to do that because complexity metrics, the old kind, they just didn’t cut it.

    When I tried to talk to the different team members and developers, I found out that nobody seemed to have a holistic picture. It was virtually impossible to get that picture out of a large code base.

    At the same time, I took a course in criminal psychology. I was just struck by the similarities in the mindset to what we needed to have in the software business. That’s how it all started. I started to think, how can we apply this stuff to software?

    Detecting Problem Code

    Derrick:
    I wanted to jump into a couple of the techniques you cover. How can forensics psychology help us to detect problematic code?

    Adam:
    The first kind of technique that I would like to introduce, and that’s actually where I started, is a technique I call a Hotspot Analysis. It’s based on a forensic concept called Geographical Offender Profiling.

    I find it really fascinating. What Forensic Psychologists do is basically they try to spot patterns in the spatial movement of criminals, to detect our home bases, so we know the area to inspect.

    I thought what if we could do the same for software, that would be pretty cool. If we could take a large code base and somehow spot the spatial movement not of criminals, but of programmers, then we could identify the kinds of, the parts of the code that really matter.

    That’s where it started, and what I do is, I start to think about where can I find that information, I realized, it was there right in front of us in a version control system. A version control system, basically records every interaction we have with the code.

    So I tried to mine source code repositories and then I looked for code with high change frequencies, then I overlaid that with the complexity analysis, which allows us to identify the most complicated code, that is also the code we have to work with often, which is a hotspot. So that’s where it all started. That’s the starting point for the rest of the analysis basically.

    Improving the Software Architecture

    Derrick:
    You also say that you can use your techniques to help improve the architecture of applications. How is that so?

    Adam:
    First we have to consider what an architecture actually is. A fundamental idea in my book is that software is a living entity. It constantly changes, evolves and sometimes degrades.

    So I came to architecture more as a set of guiding principles to help that evolution happen in a successful way. Just to give you a complete example, consider microservices, they seem to be all the rage right now.

    So that means that tomorrow’s legacy applications will be microservices. In a microservice architecture, a typical one where each microservice is cohesive and independent, so that’s basically one architectural principle.

    What you do is you try to measure and identify violations of that principle. Again I look at the evolution of the codebase in the source code repository. And I try to identify, in that case, multiple services that tended to change at the same time because that’s a violation of your architectural principles. That’s one way to do it.

    Social Biases and Working in Groups

    If you want to truly improve software, we need to look beyond technique and look at the social side

    Derrick:
    You also cover how “most studies on groups of people working together find that they perform below their potential”. Why is this and what are some of the problems teams can experience?

    Adam:
    Social Psychologists have basically known for decades that teamwork comes with a cost. The theory that I come to in my book is called Process Loss. The idea behind process loss, it’s pretty much as how a mechanical machine cannot operate at 100% efficiency all the time, so neither can software teams.

    That loss often results in the communication and coordination overhead or perhaps motivation loss. The interesting thing is when you talk to software teams about this, they are aware of the problems. Quite often we mis-attribute it to a technical issue, when in reality we have a social problem.

    In one team I worked, the developers, they noticed that they had a lot of bugs in certain parts of the codebase. They thought it was a technical problem. What happened in reality was they were having excess parallel development in those parts of the codebase.

    There were multiple programmers working in the same parts of the code all the time. So merely all they did, they said that, they complained a lot about potential merge conflicts. They were really scared to do merges of different feature branches.

    When we started to look into it, we identified that what actually happened was that, due to the way they were working, they didn’t really have a merge problem. What they had was basically a problem that the architecture just couldn’t support their way of working.

    I think that’s really important to understand that if you want to truly improve software, we need to look beyond technique and look at the social side.

    Derrick:
    What can we do to avoid such problems?

    Adam:
    First thing I recommend is always to use something I call Social Hacks. Basically it takes the social situation and tries to tweak some aspect of it, to make social biases less likely because social biases, they are a huge reason why we get process loss.

    One of the simple techniques that I recommend is, in every team, assign someone the role of the devil’s advocate. The role of the devil’s advocate is just to take the opposite stance in every discussion to question every decision made. That helps you reduce a bunch of biases because you’re guaranteed that someone will speak up. It also has the nice benefit of making teams more risk averse. There are a bunch of social stuff we can do and I also present a number of analyses that they can apply to investigate and mine social metrics from their codebases.

    Derrick:
    So what sort of results have you seen from those applying your techniques?

    Adam:
    I’ve seen that most people seem to use it for their original purpose, which was to identify the code that matters the most for maintenance. I’ve also seen some interesting uses mostly from managers. Managers seem to love the social aspects of the analysis because it makes it possible for them to suddenly reason about something that they couldn’t measure before.

    Another interesting area, is a couple of years ago, I worked with a really good test team. These testers they used to do a bit of exploratory testing at the end of each iteration. So what I did was basically I generated a heat map over the complete source code repository, so we can see where most of the development activity was, and we would start to communicate with the testers. They knew where they should focus a little bit of extra energy. That helped us to identify a lot of bugs much earlier.

    Working with Unit Testing and Code Reviews

    We’re not so much writing code. What we do most of the time is actually making a modification to existing code

    Derrick:
    How do you see current development practices like unit testing and code reviews, working with those that you’ve described?

    Adam:
    Techniques that I present, they don’t replace any current practices, save maybe wild guesses and panic near the deadline. But otherwise, they are there to complement what you already do today.

    For example, take code reviews. I often use a hot spot analysis to identify code most in need of review. To prioritize reviews as well. Unit testing is interesting, because I actually have a complete chapter in my book about building a safety net around tests. Automated tests are terribly hard to get right in practice. It’s actually something you can do, by again, measuring the evolution of the codebase, looking at application code and testing them both together.

    Derrick:
    Ultimately you say developers should optimize for understanding in their code, why is this so important?

    Adam:
    It’s important because we programmers, we’re not so much writing code. What we do most of the time is actually making a modification to existing code.

    If you look at the research behind those numbers you will see that the majority of that time is spent trying to understand what the code does in the first place. If you optimize for understanding, we optimize for the most important phase of coding.

    Tools and Resources

    Derrick:
    What are some tools that people use to mine source code data, to use your techniques?

    Adam:
    When I started out there weren’t any tools really, there were a bunch of academic tools. They were powerful, but the licences were quite limited, you weren’t allowed to use them on commercial projects, they also focused on one single aspect.

    I actually had to write my own set of tools. I actually open-sourced all my tools, because I want the readers of my book to have the possibility to try the techniques and stuff.

    If you’re interested in this kind of stuff, you can just go to my GitHub account, Adamtornhill, and download the tools and play around with them. I think we’re going to see a lot of stuff happening in this area now.

    Derrick:
    Beyond your book, are there any resources you can recommend for those interested in learning more about writing maintainable code and improving their code design?

    Adam:
    My favorite book when it comes to software design has to be ‘The Structure and Interpretation of Computer Programs’. It’s just brilliant and it had a tremendous influence on how I approached software design.

    When it comes to coding itself, I would say Kent Beck’s ‘Smalltalk: Best Practice Patterns’. It’s a brilliant book and it takes us way beyond Smalltalk. It’s actually something I recommend for everyone.

    And the final book I would like to mention is ‘Working Effectively with Legacy Code’ by Michael Feathers. It’s one of the few books that takes this evolutionary perspective on software, so it’s a great book by a great author.

    Derrick:
    Adam, thank you so much for joining us today.

    Adam:
    Thanks so much for having me here, it was a true pleasure.

    by Gareth Wilson at April 17, 2015 08:39 AM

    April 16, 2015

    Dave Winer

    It's their world we just live in it

    Something funny happens when I put my iPhone 6 and my Nexus 6 together on my desk (charging them up).

    The iPhone tries to pay the Nexus using ApplePay.

    I just realized how funny this is. Why does the iPhone (Apple) think it owes the Nexus (Google) money?

    Next time it happens I'm going to make note of how much money the iPhone thinks it owes the Nexus.

    April 16, 2015 08:11 PM

    Software and free hardware

    I just saw that JJ Abrams has an Apple Watch.

    You know there was a time when I would have had that.

    When Apple gave early access to hardware to developers who created software for their platform. I was, at one time, one of those people.

    I used to have a motto back then: "Software is made of free hardware."

    What was cool is that it worked the other way too. Hardware is made out of free software. But that was hard to say because of piracy, could be too easily misunderstood. Still, it's true.

    And it makes me wonder if there isn't still a position for a company to do what Apple used to do, cultivate relationships with software-makers.

    Pretty sure JJ doesn't write too much software.

    April 16, 2015 05:18 PM

    This is a test...

    For the next sixty seconds this station will conduct a test of the Emergency Podcasting System. Had this been an actual podcast you would have been instructed to do whatever it is you do when you listen to a podcast.

    April 16, 2015 03:11 PM

    Giles Bowkett

    What If Uber's Just A Terrible Business?

    Update: I had to block an angry libertarian on Twitter who declared me an "Uber hater" and was launching all kinds of contempt and overgeneralization my way. I also saw people retweeting this post and describing it as a general takedown of the sharing economy. So I just want to clarify: I think AirBnB is a terrific business, but Uber might be a terrible one. This is a post for rational adults who can handle nuance. If that's not you, there are plenty of other posts to read out there.

    Sometimes an industry which is very tightly regulated, or which has a lot of middlemen, has these obstructions for a reason.

    Working for any taxi service holds enormous opportunities for kidnappers or rapists, and makes you an easy target for armed robbery. In some cities, being a cab driver is very dangerous. In other cities, it's dangerous to take a cab anywhere - don't try it in Argentina - and in many cities it's dangerous for both the driver and the passenger. A taxi service with built-in surveillance could be even worse in the hands of a total maniac. And just to state the obvious, both Uber drivers and regular taxi drivers have logical incentives for driving unsafely.

    In this context, I have no problem with governments wanting to regulate Uber literally to death, at least outside of California. California is a special case, in my opinion. Cabs are completely unacceptable garbage throughout California, and the startup scene definitely skews Californian, so the typical startup hacker probably thinks all cabs suck, but cabs are gold in London, Chicago, and New York, and probably quite a few other places too.

    In Los Angeles, cabs are licensed by city. A cab driver can only operate in one "city," and can face disastrous legal consequences if they pick up a passenger outside of their "city." But the term's misleading, because the "city" of Los Angeles is really a massive archipelago of small, loosely affiliated towns. It's extremely common that a taxi cab will be unable to pick up any passengers once it drops somebody off. I lived in San Francisco before I lived in Los Angeles, and I had always assumed Bay Area taxis were the worst in the industrialized world, but Los Angeles cabs make San Francisco cabs look competent.

    (In the same way that San Francisco's MUNI system makes LA's Metro look incredible, even though both suck balls compared to the systems in New York, London, and Chicago. I'm told the system in Hong Kong puts even London's to shame.)

    By contrast, in London, you have to pass an incredibly demanding driving and navigation test before you can become a cab driver. Researchers have demonstrated that passing this test causes a substantial transformation in the size of the cab driver's brain, in the regions responsible for maps and navigation.

    Disrupting something which works great (i.e., cabs in London) is not as impressive as disrupting something which sucks ass (i.e., cabs in California). I think the tech industry overrates Uber, because the industry's headquartered in a state which probably has the worst taxicabs of any first-world country.

    Uber is obviously a disruptive startup, but disruption doesn't always fix things. The Internet crippled the music industry, but introduced stacks of new middlemen in the process. Ask Zoe Keating how that "democratization" turned out.

    In music, the corporate middlemen are this pernicious infestation, which just reappears after you thought you'd wiped it out. Artists have to sacrifice a lot to develop their art to a serious level, and a lot of music performance takes place in situations where people are celebrating (i.e., drunk or high, late at night). So somebody has to provide security, as well as business sense. There's a lot of opportunities for middlemen to get their middle on, and disrupting a market, under those conditions, just means shuffling in a new deck of middlemen. It doesn't change the game.

    In the same way that the music industry is a magnet for middlemen, the taxi industry is a magnet for crime. A lot of people champion Uber because it bypasses complex regulations, but my guess is that disrupting a market like that means you just reshuffle the deck of regulations. If Uber kills the entire taxi industry, then governments will have to scrap their taxi regulations and re-build a similarly gigantic regulatory infrastructure around Uber instead. You still have to guard against kidnapping, rape, armed robbery, unfair labor practices, and unsafe driving. None of those risks have actually changed at all. Plus, this new regulatory infrastructure will have to deal with the new surveillance risks that come along with Uber's databases, mobile apps, and geotracking.

    Uber's best-case scenario is that the society at large will pay for the consequences of their meager "innovation." But if you look at that cost realistically, Uber is not introducing a tremendous amount of new efficiency to the taxi market at all. They're just restructuring an industry so that it offloads, to taxpayers, the costs and complexities of a massive, industry-wide technology update.

    Uber got rid of inefficient dispatch mechanisms, and routed around licensing laws, but odds are pretty good (in my opinion) that those licensing laws will re-assert themselves. Those laws don't exist to preserve an inefficient dispatch mechanism, which is the only real technological change here. They exist mostly to guard against risks of criminal behavior. Those risks are still present. Like it or not, licensing laws are a very common response to risks of that nature in societies like ours.

    It's possible that those licensing laws might be gone forever, but I wouldn't bet on it. I think it's a lot more likely that Uber has a huge IPO and its stock price withers to nothing a few years later, once the slow-moving systems which generate regulation in democratic societies have had time to react. If all you're doing is building to flip, sure, you can take the money and run, but if you want an actual business that lasts, Uber might not deliver.

    I could totally be wrong. Only time will tell for sure. But I think Uber is a really good lesson for entrepreneurs in how a market can look awesome but actually suck. From a long-term perspective, I don't see how they can hope for any better end-game than bribing corrupt politicians. While that is certainly a time-honored means of getting ahead, and it very frequently succeeds, it's not exactly a technological innovation.

    by Giles Bowkett (noreply@blogger.com) at April 16, 2015 12:57 PM

    Dave Winer

    Podcasting 2.0

    In 2001, when I designed the protocols for podcasting, we were using a different Internet:

    1. Net connections were so slow that the click-wait problem was interfering with people using big media objects, and

    2. The mobile devices that could play podcasts weren't able to communicate.

    So we designed a protocol that would make it easy for your desktop computer to gather up the media objects and move them to your mobile device, probably something like an iPod, which, by the way, didn't exist yet.

    We got ahead of where the technology actually was. But it turned out well. Today there's an explosion of podcast content, all of it formed around the blueprint we put out 14 years ago.

    Today's net is better

    But the world today is different, and as a result I believe we can make podcasting much easier and richer for the listener. We can remove steps, and provide more variety.

    1. The net we use today is fast. When you click to listen to a 40-minute podcast, it's downloaded in a few seconds. And it starts playing immediately. No click-wait.

    2. The net goes with us almost everywhere with inexpensive mobile devices.

    Given that reality, one would design podcast listening software somewhat differently.

    The problem is discovery

    We're all looking for the next great podcast, not something to subscribe to necessarily, that's work -- rather something enjoyable, interesting, stimulating, thought-provoking and most important -- now!

    The perfect podcast client

    Here's how the perfect podcast client would work, imho.

    1. No preparation. When I'm leaving the house, I have lots of things on my mind. I spend time loading up my phone with fresh podcasts, when I have the time, but sometimes I'm in a rush and leave with nothing interesting on my phone.

    2. Lots of interesting shows. That's a key point. I'm less interested in subscribing to a series of shows than I am in listening to a single good episode.

    3. Social connection. I like to listen to the same shows my friends are listening to, because I love having someone to discuss these things with.

    4. Variety. I had gotten into a groove, listening to a few podcasts regularly because I could count on them being interesting to me. Mostly Planet Money and Fresh Air, with a very rare RadioLab, or a NYT Book Review podcast. But there's a lot more out there, I'm finding, now that I have easy access to more variety.

    5. Immediate. When I decide to listen I want to listen now. It should be as easy to start listening to an episode of a podcast as it is to start watching a different show on my cable TV set-top box.

    6. Ephemeral. You listen to a podcast once, and that's it. Yet the devices we use for playback are designed for music, which is not ephemeral.

    Where from here

    For a while I evangelized editorial organizations to create this product, but they either didn't understand the need, or didn't think there was an opportunity? More likely they don't think like a software developer. When I see an opportunity to make things work better, I want it to happen right now. Even if I don't have time to do the work myself.

    Well, I finally got tired of waiting. I've made the software. I'm using it now, as are a few friends. We're smoothing things out and should have something for everyone to use soon.

    We're going to start with the shows my friends recommended, when I asked them, on Facebook. If it proves useful to others, we may branch out to including shows your friends like. And on and on. I think this is the way podcasting was meant to evolve, starting in 2015.

    Update

    The product is Podcatch.com.

    A blog post explaining how the product came to be.

    April 16, 2015 12:56 PM

    Giles Bowkett

    Maybe Some Empires Never Die

    Goethe wrote a terrific paper on plant reproduction. In it, he describes how reproduction in plants occurs after a systematic buildup of the resources which enable it.

    One of the classic ideas in Western civilization is that the Roman Empire fell to savage tribes of Goths in what is now Germany. The problem with this idea is that the Empire bifurcated about 100 years prior to that, in a process quite similar to the process Goethe identified in plants. The Western half of the Empire remained headquartered in Rome, the Empire's origin, and retained the original name as well. But the other half had its headquarters in Byzantium (aka Istanbul, aka Constantinople), and began to be called the Byzantine Empire. Although the Roman Empire's Western half collapsed only about a hundred years later, the Eastern half persisted for an additional thousand years, until sometime between 1450 and 1480 (depending who you ask).

    Even that longevity looks paltry compared to my preferred interpretation, however. Assume for the sake of argument that empires exist primarily to establish hereditary advantages for the members of particular classes of people. Or, alternatively, that there is, at the core of any empire, a system which exists primarily to establish hereditary advantages for the members of that empire's aristocracy.

    Depending on which variant you prefer, you could say that the aristocracy-favoring system within the Roman Empire abandoned the Empire and took over the Roman Catholic Church instead, or that the Roman Empire abandoned many of its governmental aspects and became the Roman Catholic Church. Keep in mind that popes commanded armies and exerted governmental authority in and around Rome for well over a thousand years, all the way up to 1870. Even today, the Church may be the third-biggest landowner in the world, although its vast wealth is difficult to calculate from the outside. And I had a Latin teacher in high school who met a Catholic priest from Poland and had a conversation with him in Latin, even though my teacher spoke no Polish and the priest spoke no English.

    Consider also the British Empire. The best estimate for the official fall of the British Empire would be 1997, when control of Hong Kong reverted to mainland China. Likewise, although Britain lost its American colonies as early as the 1700s, colonies like India, Pakistan, Palestine (now Israel), and many others remained under British control until the middle of the 20th century. Although Canada became semi-independent in 1867, and Australia in 1901, Canada didn't officially finalize its separation until 1982, and Australia did it in 1986.

    Here in the States, we tend to underestimate the British Empire's lifespan, because we got out of it much earlier than average. But again, there's an alternative interpretation which attributes even greater longevity to that empire as well. As with Rome and Byzantium, the Empire bifurcated, and its older half shriveled to a non-imperial status, while its newer half - the United States - continued to thrive as an imperial power right up to today.

    The exact degree to which American foreign policy is imperialistic or democratic is wildly contested, yet its near-total domination of global politics is pretty hard to dispute. And again, just as the Roman Catholic Church kept some core elements of the Roman Empire intact, while allowing many others to atrophy, the US is quasi-imperialistic where the British Empire was unequivocally imperialistic. Both subsequent pseudo-empires have kept the original empire's language alive, as well as continuing to privilege the respective aristocracies involved, while dropping many of the core governmental and militaristic aspects of a true empire.

    I can't prove this, but I believe that if you follow the money in either case, you'll find continuity. In the Roman example, my guess is families and companies which began in Rome were able to persist either through the Byzantine Empire or the Roman Catholic Church. In the British example, my guess is families and companies which began in England or Scotland were able to persist through the American continuation of British law, or through international corporations (which were originally invented by the British for explicitly imperialist purposes).

    Whether this represents genuine imperial persistence or a vaguer kind of imperial drift is an interesting question, but not one I'm qualified to answer. It could be that empires are caterpillars, and their butterfly forms are more loosely organized and less explicitly governmental. But the continuity's easy to spot in either case, and I definitely think the commonality here is real.

    Since pretty much everyone who reads my blog is a programmer, I'll bring this around to tech.

    In the 1990s, I and many others assumed that Microsoft would die out because of the Internet. I'm sure a big crowd, twenty years before that, thought Microsoft would kill off IBM forever, too. Both these companies have been considered "empires" in their day, though never in a purely literal interpretation, of course. Each of these companies currently survives in a form which is very different from the form they held during their respective imperial glory years.

    It's possible that this is always how it's going to be, and that Google will still be with us, in some radically mutated form, two hundred years from now. Likewise, if you're a tabletop gaming nerd, I used to think the Roman themes in Warhammer 40K were ridiculous, but those mecha legionnaires look more realistic to me these days.

    by Giles Bowkett (noreply@blogger.com) at April 16, 2015 10:23 AM

    April 15, 2015

    Mark Bernstein

    The Fault In Our Stars

    So I dug right down to the bottom of my soul

    To see how an ice cream felt…

    Another book that every teenage girl you know has read, The Fault In Our Stars seems to be a story of two kids with cancer, but it's deeply interested in the the interaction between life and the stories we tell about it.

    A boy and a girl meet cute at a 12-step group for childhood cancer – itself a nicely-observed absurdity – and, one thing leading to another, they soon find themselves sharing an intense passion for a little-known novel about a kid with cancer. That novel ends abruptly and no sequel has appeared; our star-crossed readers accept that the protagonist succumbed suddenly but they want very much to know what happened to The Mother, whether her Boyfriend was good or bad, and what became of her pet hamster Sisyphus. They get in touch with the author, but he won’t commit the answers to writing. He might tell, if only we were in Amsterdam. So, two very sick kids need to get to Amsterdam.

    This is done quite well. Of course, you don’t need to address these questions through the eyes of a 15-year-old with terminal lung cancer and her first boyfriend, but that’s part of the point: plot happens.

    So, much of the book is an interesting concurrence to David Mamet’s attack on Method Acting: you don’t need to deeply understand the character’s background, because the character is a character and has no background. Nothing that’s not on the page exists; that’s all you know and if you need to know more than that, you’re screwed. (And you’re screwed in any case, thanks to the whole mortality thing.)

    I think the book, like the internal story, might to have ended right there. Instead, Green resolves everything with a maudlin coda that shows us what we’ve already been told, and which tends to recast the literary concerns as a distracting subplot in the middle of a sentimental tale of illness.

    April 15, 2015 08:02 PM