Profile

Cover photo
Verified name
Ian Bicking
Works at Mozilla Corporation
Attended Earlham College
Lives in Minneapolis, Minnesota
9,482 followers|1,384,842 views
AboutPostsPhotosYouTube

Stream

Ian Bicking

Shared publicly  - 
 
I'm moving my posting over to Facebook instead of Google+ (still blogging too, but Facebook for smaller things).
3
Harvey Smith's profile photoGregory P. Smith's profile photoNicolas Grilly's profile photoDerek Hohls's profile photo
4 comments
 
Sad to hear that. I don't live in FB land, so will miss your ideas and insights.
Add a comment...

Ian Bicking

Shared publicly  - 
5
Add a comment...

Ian Bicking

Shared publicly  - 
 
I put up a blog post, Conway's Corollary
http://www.ianbicking.org/blog/2015/08/conways-corollary.html

Wherein I speculate that when the design of organizations and the software they make differ, maybe we should let the organization structure win.
I've always read this as an accusation: we are doomed to recreate the structure of our organizations in the structure of software projects. And further: projects cannot become their True Selves, cannot realize the most superior design, unless the organization is itself practically structureless.
4
2
Michael Nielsen's profile photo
 
This is a really stimulating take on Conway's Law.
Add a comment...

Ian Bicking

Shared publicly  - 
 
I wasn't very happy with grunt, so I switched to gulp. I'm not really any happier with gulp. Webpack? Something about fool me once...

I still really like shell scripts. Through all this they've only grown on me. I'm not quite sure what to do with that.  (I came upon this, but it seems rather obscure: http://steved-imaginaryreal.blogspot.com/2015/05/shmake-shell-based-build-tool.html)
3
Drew Perttula's profile photoAsheesh Laroia's profile photoIan Bicking's profile photo
13 comments
 
I did ultimately switch the project to make.  Honestly I've been avoiding make forever now, and just needed to learn it. It's obtuse and magical to the uninitiated, but I expect worth it since it's been around forever and will be around for longer than any of these other tools.  On the odd chance anyone wanted to critique my file, it's here: https://github.com/mozilla-services/pageshot/blob/master/Makefile (though reading other people's Makefiles seems like the worst)
Add a comment...

Ian Bicking

Shared publicly  - 
 
A thought on how to add a REPL to an app or service:

Your REPL starts by creating a persistent connection to the app or service.  Could be as simple as a login and a cookie jar, or could be a socket open to the app.  Then the REPL starts a bash subshell.  In that process there are new commands for all the different things the application supports.  You get a full language and a sort of scriptability, but you don't have to implement anything beyond exposing commands.

I realize in some sense the subshell is just a way-too-fancy context manager or try/finally for bash.  But the idea of starting a shell session seems vague in bash.  And it's the session that makes the script hang together as a command language.
2
1
dennid MASters's profile photo
12 comments
 
freedom
Add a comment...

Ian Bicking

Shared publicly  - 
 
I think there might be some benefit in avoiding the term "users" and instead saying "user".  "Users" is an aggregate, while "user" is a person – somewhat mysterious, but still specific.  With "users" it's easy to think there is an average user, even though a meaningful description of a user based on the aggregate at best describes a plurality, not a majority, and perhaps a small plurality.

I haven't thought about this save for one small sentence I am writing right now, but in that one small sentence switching from "users" to "a user" helps me remind myself that I am speculating about a person's experience, not a abstraction's experience.
11
Ian Bicking's profile photoChris Lasher's profile photo
2 comments
 
Perhaps you're looking for a persona? https://youtu.be/ESOaDiv3lXA?t=27m18s
Add a comment...

Ian Bicking

Shared publicly  - 
 
And another blog post (purely technical), about the CSS Object Model: http://www.ianbicking.org/blog/2015/12/product-journal-css-object-model.html
And now for something entirely technical! We've had a contributor from Outernet exploring ways of using PageShot for capturing pages for distribution on their network. Outernet satellite-based content distribution network. It's a neat idea, but one challenge is that it's very one-way – anyone ...
2
1
Add a comment...

Ian Bicking

Shared publicly  - 
 
A new blog post about PageShot, and the unresolved security issues I know lurk within
PageShot, the product I'm working on, makes snapshots of the DOM (the live, dynamic web page) as it is rendered in your browser. There are a lot of security issues here. That DOM is intended to be short-lived, to only be shown to the one user, it might have links that are implicitly ...
2
Add a comment...

Ian Bicking

Shared publicly  - 
 
I realized why promise.then(success, fail) is so bad/hard-to-use.  This code:

  doSomething().then((result) => {
    useResult(result);
  }, (error) => {
    handleError(error);
  });

Is equivalent to the sync (fixed):

  success = false;
  try {
    result = doSomething();
    success = true;
  } catch (error) {
    handleError(error);
  }
  if (success) {
    useResult(result);
  }

But that almost never makes sense; instead you should do:

  doSomething().then((result) => {
    useResult(result);
  }).catch((error) => {
    handleError(error);
  });

Which is equivalent to:

  try {
    result = doSomething();
    useResult(result);
  } catch (error) {
    handleError(error);
  }

See?  Obvious!  Like democracy, promises are the worst form of async, except for all the others.
6
Mohamed Zenadi's profile photoIan Bicking's profile photoAaron Hamid's profile photoBrandon Rhodes's profile photo
4 comments
 
I am also confused by your first code snippet. What promises library are you using that calls useResult(result); even in the case of failure? You are saying that you have found a promises library that on failure calls both the success and fail callbacks that it has been given?
Add a comment...

Ian Bicking

Shared publicly  - 
 
Some interesting thoughts in a review: http://www.nytimes.com/2015/09/04/opinion/david-brooks-the-new-romantics-in-the-computer-age.html?smid=tw-share

"... we have been living through an unromantic period and there’s bound to be a correction. People eventually want their souls stirred, especially if the stuff regarded as soft and squishy turns out in a relational economy to be hard and practical."

Thinking of this, I am not so much reminded of a world driven by sentimentalism as ideology.  As much as we talk about it, I personally think ideology is on the decline.  We've learned how to talk about ideology with so much vigor, but I don't think it defines many individual's lives in the same way (reactively or proactively – that is, ideology isn't done to people as often either).  Instead so many of us are enthusiastic spectators of ideology.  The magnifying glass we hold to ideology makes it seem much larger in this world.

And maybe this is just David Brooks – really it probably is – but I am then struck by how economic and reductionist all these observations are:

"You should instead ask, What are the activities that we humans, driven by our deepest nature or by the realities of daily life, will simply insist be performed by other humans?"

Which is a statement to return agency to the economy over aesthetics.  We shall be aesthetic because it is demanded of us.

"He observes that 'culture in the West has become progressively more practical, materially oriented, and skeptical.' "

And here... I don't know.  Will we really change course?  I am, as predicted, skeptical.

Still, what if in all this there is something to be re-revealed in us?  To truly find this, a new romanticism, I think we'll have to turn aside from these economics.  Or else... to create ever better simulacrums of authenticity, always hustling to sell the next priceless thing.
4
Dylan Carlson's profile photoVeda Williams's profile photo
2 comments
 
I bought the book from the article you sent me, btw. I'm looking forward to it more than you know. Thank you.
Add a comment...

Ian Bicking

Shared publicly  - 
 
Once it became clear that the web was the future, did the web get taken over by those it supplanted? We tried to clean up and replace the apps with the web, and lost our way... now the web begs to be an app platform and chases someone else's dream, and has lost track of the "web".
12
1
Jeff Bailey's profile photoRohit Patnaik's profile photoNick Bauman's profile photo
4 comments
 
+Rohit Patnaik so true. Where is it heading? I think we're heading to the Von Neumann probe: self-replicating automata without all the problems engendered by their creators, those monkeys with guns. If they become truly better than us, maybe it's time they replace us after all.
Add a comment...

Ian Bicking

Shared publicly  - 
 
I'm somewhat pro-meeting, which maybe puts me at odds with the cultural norms of developers.

I think I realize some of the problem.  Meetings tend to be called by managers.  Managers have management goals.  Process, deadlines, coordination, etc.  The developer sits around in case they provide some important input on one of those topics, or to give status, or to commit to a deadline.  Nothing in that kind of meeting helps the developer's work.  And the developer tries their best to withhold, to protect their own work, but also to protect the project which actually needs that output.

In a developer-oriented meeting the topics would be decisions to make, architectural choices to consider, noting places of tension where a creative solution could be helpful.  In a developer meeting it is reasonable to take some time to look at code.  To do a bit of research – right in the meeting – to answer a question.  To brainstorm ideas.  If a problem is hard, it is reasonable that everyone go silent for a minute and ponder the problem.

In The New Science of Building Great Teams (https://hbr.org/2012/04/the-new-science-of-building-great-teams) they discuss some evidence-based observations about communication patterns.  In it they suggest that high levels of communication lead to more productivity.  By developer sensibilities, very high levels.  But mostly peer interactions – developers interacting with developers.

I'd really extend this to all the people engaged in making the product, design, user experience, user research, development, probably support and other roles.  In an ideal model there would be dozens of meetings, as different sets of these people came together to talk about what is relevant to those groups of people.  These meetings would not have clear and firm agendas, the product is the agenda, finding the agenda is some of the work of the meeting.

It's easy to blame management for the unproductive meetings.  We're calling these snooze-fest status meetings.  But I'd turn it around: professionals shouldn't depend on management to initiate meetings. Sure management can try; I try to setup meetings I think will be productive for other people.  The Standup is the quintessential example.  But we know where those so often end up: as yet another management-led status meeting.  And it's a form without a clear purpose.  Who should be in the standup?  What should we talk about? When those things are defined by management we get management-style answers.  Even better than trying to fix the standup, keep it from being necessary: make the meetings that help everyone do their work, where the topic is always execution and not prediction or planning or status.

With Project Managers and other professions focused on planning there is a danger that we defer to the specialists.  But everything needs to be planned.  The next line of code I write has to be planned. Developers have to be planners, every one of them.
The chemistry of high-performing groups is no longer a mystery.
9
2
Aaron Hamid's profile photoChris Lasher's profile photo
2 comments
 
The goal of meetings "where the topic is always execution and not prediction or planning or status" is detrimental. Developers should be involved in meetings for requirements gathering, feature prioritization, and business analysis, not just for implementation. If you don't involve developers here, your product will suffer, not to mention your developers' morale since you remove their autonomy in determining what work they will undertake.

Meetings are critical, the key is to have a strict definition for what constitutes a meeting, and avoid engagements that fail to meet that definition. In Bridging the Communication Gap, the authors explain two criteria that make an effective meeting:

1. A meeting must have an achievable outcome that, when met, indicates the meeting is over. For example, "In this meeting we will determine which feature to drop from the next release," is achievable, and ends immediately after the participants choose the feature to drop. An allotment of attendees' time is not sufficient to have a meeting; a "meeting" that ends at the top of the hour because that's when the room reservation expires is not a meeting.
 
2. A meeting must have the right attendees. A sure sign you have the wrong people in the room is attendees lose interest and get distracted. If this happens, you do not have a meeting. Stop immediately, identify the the parties that would actually be interested, and schedule the real meeting. Inviting attendees to your "meeting" on the chance that they could be involved is an anti-pattern. YAGNH (You ain't gonna need her/him). Schedule small, short meetings with 100% engagement, not long meetings with 100% attendance.

I recommend Bridging the Communication Gap for more detail. http://www.acceptancetesting.info/the-book/
Add a comment...
Story
Introduction
I'm a programmer.  I work in Mozilla Labs, where we try to figure out new ideas for the web and browsers.

I've been doing open source programming since sometime in college.  All my actually important contributions (and many projects) have been in Python: Paste, WebOb, WebTest, pip, virtualenv, FormEncode, MiniMock, and a bunch of others, quite a few of which no one else ever cared about ;)

Since moving to Mozilla, and because of events in my personal life, I've stepped away from most of those old projects.  Hopefully it will leave room for new projects, but I also find myself in a period of reinvention, moving from server to client, from Python to Javascript, and frankly I'm just older.  I remain dedicated to free/open source software; and while that is practical and has been professionally rewarding, I am more motivated by the principle and politics of open source than the engineering.

I work remotely out of my home, in the Powderhorn neighborhood of Minneapolis.
Education
  • Earlham College
    Computer Science and Math, 1995 - 1998
  • South High School, Minneapolis, Minnesota
    1991 - 1995
Basic Information
Gender
Male
Work
Occupation
Computer Programmer
Employment
  • Mozilla Corporation
    present
  • Imaginary Landscape
  • The Open Planning Project
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Minneapolis, Minnesota
Previously
Minneapolis, Minnesota - Richmond, Indiana - Chicago, Illinois