warpedvisions.orgwarpedvisions.org - Podcast Feedhttps://warpedvisions.org
Stuff to make you thinkTue, 11 Dec 2018 00:23:50 +0000https://wordpress.org/?v=5.0.4hourly1https://wordpress.org/?v=5.0.4121964808A JavaScript link mashup for Winter 2017: Things I used and liked in the JS universe this year.https://warpedvisions.org/2017/12/11/a-javascript-link-mashup-for-winter-2017-things-i-used-and-liked-in-the-js-universe/
https://warpedvisions.org/2017/12/11/a-javascript-link-mashup-for-winter-2017-things-i-used-and-liked-in-the-js-universe/#respondMon, 11 Dec 2017 02:20:39 +0000robotponyhttps://warpedvisions.org/?p=5772017 was a good year for JavaScript. The newer language features are now part of our daily routine. Tightly integrated CI and packaging scripts are the norm, and we have a huge sea of libraries and tools available to us. The core JavaScript frameworks have settled down and matured to the point that we can be confident in JS as the base for large-scale commercial projects.

Here are a few of the main JavaScript things that impressed me this year:

GraphQL for Node.js is the most exciting library of 2017. GraphQL (the QL stands for query language) is a natural evolution of APIs: it makes it easier to ask a web service questions without having to work as hard for the answers. While RESTful APIs provided a clean way to publish and present data, building APIs based on static object definitions force a lot of work on the things that need the data, which is wasteful and complex (as you end up with much more data than you need). And while including the concept of server-side queries isn’t new to APIs, GraphQL does it with a simple syntax that fits nicely into the JS world.

One of the ways to gauge the success of a UI framework is in what gets built with it. This Fall I found a solid spreadsheet component. I’ve also been using SemanticUI and its React bindings, though I am a bit worried about their slow pace of updates. There are a few commercial UI kits, like ExtReact and Webix that have some legs, though I’d love a richer open kit that we could all contribute to.

I’ve worked to improve how we develop software this year with things like deeper CI, better Lint and formatting tools, and better practices. In our quest for improvement, I found Prettier, a JavaScript code formatter that is pretty smart about line lengths and readable code. You can use it in your build scripts, CI, or your favourite editor.

Speaking of editors, I switched to Visual Studio Code this year, which is built on Electron (Node, Chromium, and V8). VSC replaces both Atom and Sublime, as well as my older favs Coda and Espresso. Visual Studio Code plays well with all of the recent linters, CI, build tools, and other gizmos. It performs well for coding tasks in JS and the various web formats I use regularly. When I work with larger text files, however, I’ll still switch to the Vim of Mac (TextMate), or actual Vim (though I’m getting pretty rusty with that these days).

There was a time when I couldn’t imagine Microsoft as a leader in OSS or web tech, but they’ve found their mojo with VSC and have a steady release cadence that’s downright impressive.

One of the best things about JavaScript in 2017 was the huge selection of mature and featureful libraries.

Formatting dates in JavaScript, for example, has always been a bit of a pain, but libraries like date-fns make it a breeze. Similarly, CLI apps have always felt a bit clunky to build with NodeJS, but I found that by using Ink, a React-like library and components for CLI apps, I write a lot less fiddly console.log() code. Ink also makes it easy to write more complex CLI tools, which could be especially good for the ecosystem.

In terms of packaging tools, I haven’t sided on a single bundler this year. That said, I do find webpack easy to set up and use. It’s one of the current generation of build tools, and has simpler, clearer configuration than its predecessors. ParcelJS is on my radar as a simpler way to bundle JS applications, but I haven’t had a chance to use it on anything big yet.

And while there are too many JS libraries to mention, the exciting thing is that there are huge communities and tools for recommending great libraries, like MicroJS and JavaScript weekly.

Storybook is one of those unexpected tools: it’s a mature UI builder for ReactJS, that feels about the way a UI builder should feel these days. I didn’t find myself getting lost in a tonne of automated code generation (i.e., it felt surprisingly lightweight). I haven’t used it in production yet, but I’m looking for ways to make it part of my prototype toolchain for early 2018.

And finally: as JS matures past ES6 and ES7, the language is getting easier to teach (and learn). Here are some resources to help you learn more about the evolution of JavaScript:

]]>https://warpedvisions.org/2017/12/11/a-javascript-link-mashup-for-winter-2017-things-i-used-and-liked-in-the-js-universe/feed/0577A savoury media diet for a cold and somewhat dreary Winter (2018)https://warpedvisions.org/2018/03/18/a-savoury-media-diet-for-a-cold-and-somewhat-dreary-winter-2018/
https://warpedvisions.org/2018/03/18/a-savoury-media-diet-for-a-cold-and-somewhat-dreary-winter-2018/#respondSun, 18 Mar 2018 04:36:05 +0000robotponyhttps://warpedvisions.org/?p=646One of my favourite reads is Kottke.org, a blog by Jason Kottke. Calling it a blog is a bit of a slight: it’s more of a magazine, like a proto-New Yorker. It’s thoughtful and relevant, weaving current events, artsy things, various interesting edges of tech, and topics about general humanity.

Kottke has been killing it since ’98, about as long as WarpedVisions has been around (though Kottke is better in every way). One of his regular columns is his Media Diet, a post I look forward to reading whenever it appears. There is something great about seeing someone else’s obsessions and indulgences: there’s a bunch to learn and inspiration to be had. So I’m in, here is the best of my media diet from this dank Vancouver Winter.

Books and other things in print. I don’t read as many real books and magazines as I used to. Much of the good stuff has moved online, though there is a bit of a void for great fiction and ridiculously deep reference on the web. When I do sit down with a great book, it’s an event, with headphones, a glass of wine, and is one of those things that makes the muse happy.

I spent a weekend re-reading The Short Stories of Ray Bradbury, while buried in my back catalog of Zeppelin, Queen, and other 70s greats. I read most of these stories as a child, as there were so many Bradbury collections at the time. His writing evokes memories of the early days of home computing and popular science, even though they were mostly written a generation before my childhood. The book is a meaty 1100+ pages and beautifully bound. While my original hardcover is pretty worn, it’s one of the coolest things in my collection.

I bought myself The Flavour Bible over the Winter break. This book was perfect for where I’m at in the kitchen: it fits somewhere between an encyclopedia and thesaurus for how food pairs, relates, and what it all means to various cuisines and cultures. It’s exhaustive and somewhat exhausting to read, but one of the most important references I’ve seen for food, ever. It’s also full of tidbits and quotes from chefs from around the world, including Vancouver’s own Vikram Vij.

Lucky Peach ceased publication with their Fall double issue. The magazine was a collaborative effort between chefs David Chang and Peter Meehan (initially published by the great McSweeney’s, later going solo). It was a sort of Wired Magazine for food: weird, wondrous, and fantastically laid out. I re-read my last few years of the magazine on a snowy Saturday with some mixed beverages.

Essays and long reads. Most of my media diet these days can be found online. Until recently, I wasn’t sure what I thought about the shift. I’ve made peace with it, even though publishing and typography in the browser are still in their early evolutions. The writing is there, and the rest is improving steadily.

The Wire, 10 years on plays on the nostalgia for one of the best shows in history. It succeeds, too, as I want to re-watch The Wire again.

The Lottery Hackers is one of those Huffington Post essays that gives me hope for long form writing on the web. It covers the incredible story of Jerry and Marge and their epic lotto hack, in a way that feels like the writing in Wired Magazine from the 90s. It’s worth the time to read, and (I hope) is a sign of how great magazines can exist on the web.

Does Recovery Kill Great Writing? is a story of addiction and creativity. I have a soft spot for stories about addicts and their struggle, and the question of how it affects the creative process is crucial to helping people out from under their monsters. The NYT is another example of how great writing and publishing can exist on the web. There is hope.

Speaking of Wired Magazine from the 90s … The Curse of Xanadu is one of the great essays of their print magazine. It follows the story of Ted Nelson (who is also interviewed in Lo and Behold below), a pioneer in computing as well as a sort of philosopher of tech. The essay follows the frustrating path of his vision for better ways to structure information, and how even a brilliant vision isn’t enough to ship working software. And to think that it’s another 20 years later should be enough to break any software developer’s heart (if they have one).

One of the things the web brings us that didn’t exist much in print is the whole teardown phenomena. Ken Rockwell (the somewhat cantankerous photography pundit) does a thorough analysis of the new Apple Lightning Adapter Audio Quality. I can’t vouch for the accuracy here, but the analysis made me smile, as I love to see people dive into the details and talk about it.

For a more complete list of (most of) the essays I read, you can follow my Instapaper feed.

Streaming movies and series. I don’t see many new movies these days, or at least when I do it’s from the comfort of my living room. It’s not that I don’t like the theatre, rather I think that a great movie deserves to be savoured and repeated (and why pay for it more than once?). Streaming is an amazing shift in consumption, as great media can be binged and repeated as often as desired. This is mostly good, I think.

Blade Runner 2049 was a beautiful film. It stitched together dreamy visuals with a relaxed story that was interesting enough. I’ve only seen it once, so I won’t rate the story further, except to say that I think it’s worth a watch for the visuals alone.

Edgar Wright’s Baby Driver was a clockwork movie, pushing the art of heist movies to a new level. I have to admit the music wasn’t quite my jam, but the movie is so well constructed that it didn’t really matter. I saw it twice, hoping I’d enjoy the story a bit more, but in the end the details, the beats, and the timing are enough to make this well worth watching.

Burnt is a slightly slower paced Chef, telling the story of an obsessive chef’s quest for his third Michelin star. The movie is much better than its ratings, though it lacks some of the quirk and redemption of Favreau’s Chef. The photography is superb, showing the exacting beauty that is possible in a well run kitchen. There’s inspiration to be found in Burnt, so I strongly recommend it for a quiet Sunday afternoon.

Shameless is a dark comedy based on Paul Abbott’s Shameless (originally on Channel 4). Shameless (US) is directed by John Wells, famous for his work on ER, The West Wing, Trinity, and more recently Burnt (see above). I found Shameless the best dark drama comedy since Californication and Weeds. Shut up and watch it already.

Queer Eye is a surprisingly adorable “reality” show. It will make you smile and is best watched with a glass of wine and your SO. You’ll learn something, you’ll smile, and you may even no-I’m-not-crying-shut-up-there’s-something-in-my-eye enjoy it.

The best thing I’ve seen in years appeared on Netflix last month: Ugly Delicious. It’s David Chang’s new docu-series, a sort of Lucky Peach meets Mind of a Chef. It is the perfect way to get excited about food, travel, and film. And while I’ve seen a few critical reviews complaining about the underlying agenda of the series (that Asian food is awesome), I felt it was more about Chang’s journey of realizing that truth for himself. The series has inspired me more than Lucky Peach, to both eat and cook more, as well as to travel and look at film as an important path to inspiration.

Lo and Behold, Reveries of the Connected World (Netflix). Werner Herzog tells a story in a series of interviews with technology and philosophy greats of the 20th century, covering topics around the impact of the huge leaps of the last several decades: things like the internet (and ridiculous IoT), AI, robotics, and where they intersect with humanity. It’s an important exploration intended to make us pause and to think a bit more about what and why we’re creating these things.

Full Circle

It’s interesting to me that WarpedVisions started as a very raw link log in the 90s, and that it’s really part of what it should have been all along. Sometimes it takes those persistent and successful peers to remind us of that.

]]>https://warpedvisions.org/2018/03/18/a-savoury-media-diet-for-a-cold-and-somewhat-dreary-winter-2018/feed/0646Tip: Become a part of your side projects.https://warpedvisions.org/2017/05/02/become-a-part-of-your-side-projects/
https://warpedvisions.org/2017/05/02/become-a-part-of-your-side-projects/#respondTue, 02 May 2017 05:58:21 +0000robotponyhttps://warpedvisions.org/?p=433I had a realization last week:

How can it be more me? If I’m not in it, can I get into it?

I’m an idea guy. It’s why I love designing software, both in terms of system design and user experience. I love designing and developing products too. It’s something that can get me fired up, keep me from sleeping, and keep me motivated through even the darkest, rainiest days.

It’s easy to conflate the love of designing things and your favourite ideas with projects you should actually work on yourself. Not every idea is worth doing. Not every idea is suitable for a given company, team, or even an individual to do. The thing has to fit the people making it somehow. Ideally the ideas and designs embody something that is at the root of those people, as the result will be something that is much more than the sum of its parts.

So I had one of those ideas

Like many people, I use task lists to organize the projects I work on. I write the tasks on a large piece of paper, organizing them in lists and columns around the sheet. In the center of the page, I summarize the high points of all the lists into a single focus list, which I separate visually from my others on the page. This list has very specific tasks and goals that serve the various projects and sub-projects on the page. Often finishing the focus list is an incredibly successful sprint of work towards some larger goal.

One of many focus list wireframes from 2016

I’ve been thinking about building a tool for my focus lists for a few years now. I’ve used the project as a way to practice sketching various UI designs, looking for balances between skeuomorphic, spacial, and domain-centric ways of thinking about the problem. As a practice project it’s been fun.

The other day I read that Microsoft planned a shutdown of a recent acquisition, Wunderlist. I wondered if I should dust off my focus list designs; I could easily commercialize the idea and build it myself. The problem was that I didn’t bother to stop and ask myself if it was something I should do. I didn’t wonder if it fit who I am.

When I dug into the question a bit, I found a list of reasons why I wanted to build a task-list application:

My idea of focus lists is pretty great

I know how to design and build web things

I have a bunch of designs that I’d love to build

Most of my reasons to build a TODO tool are all pretty shallow.

If I ask myself harder questions, the project seems way less obvious:

Does the project fit who I am?

Are task lists something I get excited about?

Should I really build a task app?

I had to admit to myself that I’m not passionate about productivity tools. I use them and I need them, but I don’t talk or write about them, as they’re more of a necessary evil than something that excites me.

Looking more objectively, a task-list project just doesn’t fit me. It isn’t very Bruce. I love the idea. I’m proud of my clever design and approach. But the thing itself isn’t something that lights a fire under me. It doesn’t get me excited for the thing, rather I’m more excited about the hubris of it.

From point A to point B

To figure out if a project is really me, I think I have to do a few things. First, I have to imagine that it’s the only thing I’m working on. Am I still excited a month from now? Am I talking about it? Am I willing to do the boring work to finish it?

I also have to imagine if it’s something that fits what I’ve done already, at least the stuff I’m still excited about. It needs to fit where I’m going too. If I draw a line through those things and extrapolate, do I like where it points? Is the thing it points to a better version of me?

So I now have a new question for my side projects: is this project really me? Is it a very Bruce thing? I have lots of project ideas that are totally me. I think I’ll focus on those.

”A common example is process as proxy. Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right. Gulp.“ (Jeff Bezos)

This is a quote from a Jeff Bezos letter to the board, talking about internal metrics and improvements. Sometimes when you add a process to a problem, the process can become the focus and not the outcome.

In PM land we use tools and techniques like burn down charts, sprints, and spikes. You can get obsessed over getting these things right, and fail to ship effective, quality software. The special language used in and around these processes adds to the problem too, as the language ends up feeling like an accomplishment in itself. Too much focus on the pomp and circumstance of a process takes away from actually building great software.

e.g., Let’s put a pin in this …

The real value isn’t in the process or lingo, it’s in doing things better and making better software within profitable budgets. It’s something that’s been rolling around my head for a while, and Bezos describes it nicely.

I was talking about basic project management principles with a friend the other day, when I came across this Bezos quote. It sparked a discussion about software development processes, including hitting a few topics that I think are especially distracting in software development.

Do you use sprints, burn down charts (etc.) in software project management?

Yes, these are fairly common software management tools now, and I use some aspects of them. Now of course we don’t say “spike” ever, or “tent pole”, but we do plan sprints of flexible durations, and we’re always aiming for minimum viable steps and frequent releases.

I think it’s a common mistake to set fixed durations with sprints, as it can shift the focus to succeeding at the sprint versus shipping something viable (i.e., both useful in the short and medium term). It can really deflate the team if sprint durations make no sense, as developers pick up on goals that aren’t about useful or quality software.

Fixed duration sprints can also force poor decisions, as your primary goal is time and not the other factors important to software. If you relax your use of sprints a bit, you can pick sprint times that fit the underlying problem better. The real goal with sprints is to focus on scoping the project, and improving the overall tempo of development. Sprints shouldn’t be truncating quality for minimum viability, nor should they be pushing teams to burnout faster. Really, all we want from sprints is a framework to keep us focused on the right features and a strong speed of development.

Does ‘sprint’ equate to ‘crunch time’?

No, it shouldn’t.

This is a great question. My friend is coming from another domain, specifically small-scale custom manufacturing. He’s not fully familiar with software development terminology (though he’s vaguely familiar with how software is generally developed). Conversations like this are a great reminder that the language we’ve developed in this industry is insular, even though it is based on what we think are clear metaphors. When you think about if from an outsider’s perspective, you can see how arbitrary the language is, and how the imagery doesn’t fit perfectly.

This is especially true with terms like sprint. You can’t literally sprint all of the time, as it suggests expending the maximum amount of energy over short distances. Software projects are anything but short, and the idea of sprinting through the entire thing is absurd. The PM concept of sprints doesn’t match the real world use of the term very well.

A sprint is like a focused mini project. To some degree, it’s like having a personal trainer guide your workouts and push you a bit. The idea is to use the mechanism to help you push to a clear goal.

More traditional PM structures projects as very long, boring wanderings through the desert. Waterfall projects, for example, don’t produce workable software until much later in the process.

We might say, “we’re authorizing blanket overtime” which tells the guys we need as much effort as we can get right now. There are some tasks on the shop floor which simply can’t be done faster, so we would add more hours. Or worst case a second shift. There’s huge inefficiency in adding a second team.

That is a common manufacturing practice for increasing bandwidth, but sprints aren’t only about increasing output (though the term strongly suggests that). A sprint is more like setting up a smaller shop, with a special, focused project.

Ahhh. We would job things out to other manufacturers …

That’s not quite it either, though I do find using sprints for special ops is especially useful, as you push the focus of the tool to problems that need special focus.

The concept of project sprints was really to make things feel more focused and tactical. It was a backlash on the traditional waterfall planning (i.e., requirements, design, implementation, and testing).

But after using sprints a bunch, they can become empty words for traditional project management things. The trick is really to keep sprint projects focused on smaller, but useful deliveries.

Sprints really just become project phases like those in the waterfall model, except that you’ve organized the deliveries differently. You try to partition design into things you can deliver on shorter intervals, rather than aiming to deliver one giant thing at the end. There is a huge advantage to delivering these small and useful pieces early on, as you learn a lot about what works (and doesn’t) well before the end of it all.

I was saying earlier that the concept of sprinting suggests running fast, which if you think about it is so expensive in terms of long-term motivation and energy. It’s an odd side-effect of the name itself, as running fast isn’t part of the definition of a software sprint, yet the term implies it so strongly.

There’s this pattern of making special languages for our formal processes, based on the ways we approach building software. It’s difficult to find ways to describe processes that don’t eventually become ideology or warped in some way. The simple act of naming the parts can change how we think of them, if we lose focus on the real goals.

I can’t think of an analogue in manufacturing …

It eventually boils down to the same set of problems as with projects in any industry. I’ve seen special-ops style projects in manufacturing before:

One re-manufacturing mill I worked with started a finger-joint mill. They took their best staff and had them design and built the new plant in stages, apart from their traditional management techniques. They split the work into smaller chunks, and had something up and running early.

Ahh, I see!

They treated it like a special thing, which helped them escape their traditional planning techniques.

Of course sprints aren’t really just special-ops anymore, but that’s where the concept started from. We used to say “Let’s push hard and get this out by next week”. We used this push mindset well before Agile methodologies were well-defined, and sprints were really an extension of that.

Yeah we did that too, but I guess we were so unfocused that it was normal to work on random projects.

In the end it’s just different words for the same things. The mindset of making projects smaller and focusing them on early and useful releases is the best part of sprints. The concept of isolating design to reduce scope is also great.

Really, sprints cut across the grain of the old waterfall style planning, repackaging a lot of the risk to earlier deliverables. It really only works if your sprints produce production quality deliverables though, which is why it’s so important to avoid serving the process over the goal of building something incredible.

Sprints are a good example of allowing the process to become the focus, instead of obsessing over what you’re making. This is what frustrates me the most about software development methodologies: when great concepts become ideology and the underlying intent is lost. You start spewing the bullshit terms without even thinking. They become bullshit when the term is the focus, rather than the outcome.

e.g., Let’s spike this feature for the next sprint.

Or, Our sprints are only 1 week, so that story is too much for us right now …

It’s disingenuous to use these words all the time. It allows a lot of passive-aggressive behaviour too, as you can use the noble act of following the process as a way to beat down legitimate concerns about what customers or the business needs.

What I see happen is that smart people can control production and planning by using the process language in clever ways. Arguing things for the sake of process can be a sign of that problem, i.e., elevating the process above the intent.

The problem isn’t in the process, however, it’s just a reminder that it’s easy to focus on the wrong goal. Sticking to your process is often a much clearer path than figuring out what your users really need, or how to design that thing in such a way that it’s a viable business. And because the process can be easier to succeed at, it becomes an easy target for people on a career path.

As software leaders we just need to remind our people to apply the process and tools for the outcome. We want to build useful things for our fans and users, and we want these projects to serve the needs of the business. The processes and methodologies are just tools to this end, and not the end itself.

]]>https://warpedvisions.org/2017/04/22/my-love-hate-relationship-with-sprints-agile-and-software-development-processes-in-general/feed/0403Tips for Avoiding Technical Debt and Regret.https://warpedvisions.org/2016/08/15/tips-for-avoiding-technical-debt-and-regret/
https://warpedvisions.org/2016/08/15/tips-for-avoiding-technical-debt-and-regret/#respondMon, 15 Aug 2016 22:44:31 +0000robotponyhttps://warpedvisions.org/?p=308Last week I was talking about how it’s easy to conflate debt and regret when it comes to technical decisions. Technical debt is the set of simple, shorter paths in software development that you follow intentionally. Regret is more about getting lost and following unsafe paths, often blissfully unaware that you’re lost. Technical debt will feel good in the long run, as it helps you get somewhere faster at a reasonable cost. Regret, on the other hand, feels bad, as you can see the wasted time and effort spent on a path that was clearly followed by mistake.

It’s easy to feel unqualified to measure technical decisions, especially if you’re not technical. You may be disconnected from the planning process or you may not understand the jargon and details of an approach. How can you ask intelligent questions about risk when you feel so separated from what’s happening? How can you make clear decisions about risks with incomplete technical knowledge?

Luckily, most regrettable technical decisions fail to satisfy even the most basic of principles, and risky debt is all about the poor ratios of cost versus gain.

Know the scale of your product and features

In terms of debt and regret, you can measure the risks by understanding two things:

the basic scale of your product, and

the basic dependencies in the features your product offers.

Understanding these doesn’t require much technical knowledge, and that understanding is anchored to what your product does. Thinking of risk starting with facts and how they relate to what your product provides you a rational base to start from.

Scale includes things like the number of users, the size of the things they do, and how fast they need to do them. When you have a lot of something, you can ask questions around your features and those abundant things: how can we report on X with Y users? Can we also do Z?

Dependencies are simply how the features and pieces of your product relate, as there will be certain features that are more important to your product than others. Those features are riskier, as your system wouldn’t be viable without them, and other features may not be possible without them. Our product has to do X to do Y and Z; what if X is too slow? What if we can’t do Y?

Bigger, more fundamental things are obviously more important. Understanding the scale and dependent risks gives you a set of facts you can use to anchor your thinking. The truths don’t change as you develop your software either, unless you change the focus of the product.

Know which risks to focus on

To simplify thinking about risk, you can place it on a gradient of principles:

Decisions that are never questioned or justified represent the risk of the unknown and unseen.

Decisions that follow known bad paths represent the risk of the known bad.

Decisions that don’t follow known good paths represent the risk of the likely bad.

Decisions that follow new paths represent risk, that of the unknown.

Decisions about the most fundamental parts of your system are risks of increased or root dependency.

Decisions about the biggest parts of your system are risks of scale.

Decisions that defer costs are a risk of future expense.

Decisions that prevent key opportunity are a risk of reduced momentum.

When you think about risks in terms of principles, you can separate some of the technical from the rationalization. When a team wants to build a custom framework (a classic example), it’s easy for a non-technical manager to see that the approach isn’t a known good, and that it’s a new path. These principles don’t prevent following that path, but they do make it clear that the risks and likely costs are not insignificant.

Know when to consider risks

Considering risks is a crucial part of a healthy software development process. Knowing the size and dependencies of your product gives you a place to anchor your thinking. Identifying the bigger, more fundamental issues in your product using principles helps you identify the most basic major risks, as well as giving you a way to describe the risks themselves.

But, do you consider every risk? Do you weigh every change?

Most organizations can be improved by considering the risks of only a small portion of their technical decisions. Anything foundational or large should be considered carefully, and anything that violates one ore more of your team’s core principles should be actively avoided.

Know your history

Finally, another great way to identify risks is to learn more about the history of software failures. The principles that identify risk are clear throughout the history of failed projects, and the ways that the risks remained hidden help to identify future failures.

]]>https://warpedvisions.org/2016/08/15/tips-for-avoiding-technical-debt-and-regret/feed/0308💰 Being Honest About “Technical Debt”.https://warpedvisions.org/2016/07/17/being-honest-about-technical-debt/
https://warpedvisions.org/2016/07/17/being-honest-about-technical-debt/#respondSun, 17 Jul 2016 16:58:22 +0000robotponyhttps://warpedvisions.org/?p=296I don’t like the term technical debt. We mostly use it without thinking, and it’s often the wrong way to frame the value of our software designs. Most of the time we’re being dishonest when we call our decisions debt, and unless we’re planning out the general long term costs of our approach, it’s not debt at all.

With financial debt, money is mostly money, regardless of the source. The terms of a loan are known up front when we borrow money, and those terms may or may not be satisfactory. Any decision to borrow is based on a known commodity, and on the need and the terms, both compared with the gains. Taking on debt, at least in business, is an informed and unsurprising proposition. Debt is often a rational choice for a business too, if the risk is low and the return is favourable. It’s rare for a company’s investors to allow a business to take on financial debt that isn’t clearly understood.

With technical debt, both the commodity and the terms can be fuzzy. What’s being borrowed isn’t always known, and the risk/reward isn’t always easy to measure. If technical decisions are a commodity, they can be a volatile one. If the cost of those decisions are the terms, then they’re not always agreed upon ahead of time. Taking on any debt without knowing both the values of the commodities and the cost of the terms makes it impossible to think about the proposition clearly.

At best, we treat software technical debt like consumer debt, where we blissfully ignore the commodity and the terms of our choices, focusing only on our immediate need. At worst, we label our poor technical decisions debt (especially our predecessor’s). It’s a lazy phrase, a cop-out, and is a costly way of doing business.

There is a place for actual technical debt in software projects, but it needs to be informed and planned. For example, it may not make sense to invest in a fully scaled system before proving out a concept. Starting down a simpler path can be the better choice, as you can reduce the overall risk with a moderately increased cost. That simpler path has a future cost, of course, but it can be a rational decision to defer the full cost of the solution until you know more about the features and fit to the market. Taking a split risk in approach can be good for the business, but the risk and terms need to be part of your planning.

Technical debt that rears its head unexpectedly, on the other hand, isn’t debt, it’s regret. We often regret our past decisions, as they can be very costly and inconvenient. But if we treat our remorse as debt, then we’re admitting that we’re not really suited to making technical decisions for our business. We’re missing the value of what technical debt can be, which is a predictable stepping stone to future growth.

We need to be honest about our past technical choices. Debt is something that we plan for, that has a known future cost. Regret is something that we’re remorseful for, but represents a historic lack of planning and unquantified risk. We should be taking risks in the business of software, but they should be sincere and measured actions, otherwise we’re fooling ourselves into thinking that we’re being rational in our business.

]]>https://warpedvisions.org/2016/07/17/being-honest-about-technical-debt/feed/0296Do just one more thinghttps://warpedvisions.org/2012/03/28/just-one-more-thing/
https://warpedvisions.org/2012/03/28/just-one-more-thing/#respondWed, 28 Mar 2012 20:30:04 +0000robotponyhttp://w28.warpedvisions.org/?p=41You start the day finding consciousness. Slowly or quickly, it doesn’t matter … you become aware of the world incrementally. Maybe you hit the snooze button once? Twice? Or maybe you wish you did. If you’re like me, you’ll find some caffeine and make the trek to work.

And if you’re lucky you will find yourself in your office quickly, alert, and ready to go. You work your way down your list of tasks until your customers, coworkers, or biology interrupt you. It may be minutes. It may be hours. The question is, what do you do when you’re interrupted?

I have a suggestion. Do just one more thing. If it’s not rude, do another. And another.

This is how things get finished: by doing them when the doing is good. And moving just one more inch gets you closer, while you’re brain is focused, and before you get pulled into something else.

Of course there are other tricks to getting things done. Doing the right things, for example. Working with a healthy mind; finding ways to focus and hone your skills. But doing just one more thing is an easy hack that works wonders.

]]>https://warpedvisions.org/2012/03/28/just-one-more-thing/feed/041Icons and fan arthttps://warpedvisions.org/2018/07/17/icons-and-fan-art/
https://warpedvisions.org/2018/07/17/icons-and-fan-art/#respondTue, 17 Jul 2018 23:06:03 +0000robotponyhttps://warpedvisions.org/?p=709When my sketchbook is stale and I’m not feeling inspired, I look to pop culture for inspiration and ideas. I’m also a fan of other artists, and channeling some of their works through my own hands is immensely satisfying. It’s an exercise that pushes you to analyze and rethink a thing that’s interesting to me, and I always end up learning or discovering something new in the process.

A Super Mario Star (single colour, carved in EZ Cut)

No Face (2 colour, Quick Kut)

Jake the Dog and Lady Raincorn (single colour, Quick Kut)

Tortoro (single gradient, EZ Cut)

]]>https://warpedvisions.org/2018/07/17/icons-and-fan-art/feed/0709Lee Valley: an unexpected place to buy carving toolshttps://warpedvisions.org/2018/05/17/lee-valley-an-unexpected-place-to-buy-carving-tools/
https://warpedvisions.org/2018/05/17/lee-valley-an-unexpected-place-to-buy-carving-tools/#respondThu, 17 May 2018 22:44:03 +0000robotponyhttps://warpedvisions.org/?p=696I was looking at buying a set of PFEIL carving tools this year, but was holding off as they’re pretty pricy. I expanded my search a bit and found a similar set from a local Canadian company, Lee Valley Tools. They’re hardened steel with a comfortable wooden handle. They sharpen easily (and keep their edge well), and feel like they will last a lifetime. They’re also ⅓ the price of the PFEIL tools.

]]>https://warpedvisions.org/2018/05/17/lee-valley-an-unexpected-place-to-buy-carving-tools/feed/0696A quick review of linoleum and vinyl block printing art blockshttps://warpedvisions.org/2018/02/22/a-quick-review-of-linoleum-and-vinyl-block-printing-art-blocks/
https://warpedvisions.org/2018/02/22/a-quick-review-of-linoleum-and-vinyl-block-printing-art-blocks/#respondThu, 22 Feb 2018 20:56:36 +0000robotponyhttps://warpedvisions.org/?p=666A coworker was asking me what I used for linocut, so I made a chart of the blocks on my desk. There are several types of blocks that I don’t have in my supplies (like mounted block and clear blocks), but the ones I use are a pretty common set of hobbyist materials.

I love carving the easy cut black: it’s soft, makes great edges, and it’s cheap in my area (at Opus). But, transferring artwork to a black plate is super inconvenient.

The safety kut style blocks are a lot of fun to work with, but the edges tend to crumble a bit. It’s also pretty pricy, but great for kids to start out with.

The flooring vinyl is school flooring I bought over 20 years ago (at auction). It’s hard, but cuts a sharp edge and is the cheapest of all the supplies I have. If you warm it up a bit, it carves nicely, and it can print hundreds of copies without degrading. It does have a bit of surface texture, but this tends to make prints more interesting.

The battleship grey block is the classic school art department block. It takes a good edge, is fairly cheap, and carves easily enough once warmed up.

The golden and wunder cut blocks are interesting. I got these from Dick Blick, and they smell wonderful (like linseed and sawdust, probably because that’s exactly what they are). They carve fairly easily, but the edges crumble a bit. Regardless, these are very affordable and great for prints with patterns.

]]>https://warpedvisions.org/2018/02/22/a-quick-review-of-linoleum-and-vinyl-block-printing-art-blocks/feed/0666Art on brand: lemony lemon printshttps://warpedvisions.org/2018/01/05/art-on-brand-lemony-lemon-prints/
https://warpedvisions.org/2018/01/05/art-on-brand-lemony-lemon-prints/#respondFri, 05 Jan 2018 22:55:07 +0000robotponyhttps://warpedvisions.org/?p=701Occasionally I like to sketch and carve things around our lemony brand. It’s fun to think sideways around our polished brand marks, dreaming in colour and texture. These prints don’t represent anything we would ever use, but the exercise was a good stretch for me (and good practice).

This is a second print of the plate with an attempt at layering a textural plate over top. I still need to work on this technique, but I do like the extra texture it adds to a print.

]]>https://warpedvisions.org/2018/01/05/art-on-brand-lemony-lemon-prints/feed/0701Simple methods: the triage boardhttps://warpedvisions.org/2017/11/14/simple-methods-the-triage-board/
https://warpedvisions.org/2017/11/14/simple-methods-the-triage-board/#respondTue, 14 Nov 2017 19:22:08 +0000robotponyhttps://warpedvisions.org/?p=636Some of my most productive business tools are the simplest. Take the triage board. It’s a whiteboard that hangs over my desk that has a list of my current projects, with magnets marking what I’m working on next. Weekly I erase the board and re-prioritize my projects, and daily I scribble notes and move the magnets as I work.

These concrete tools are about focus, flexibility, and the least amount of investment possible. It’s critical to work on the most important things, and important to know what’s next. Seeing the list of clients and projects helps me understand where I stand in terms of bandwidth too, using the simple, physical limits of the size of the board and legibility of my writing at smaller sizes.

I also use other real world hardware and the occasional piece software for other aspects of the business of software, but the board is big, and bold, and in my face.

Charting a course with post-it notes

I also use PostIt notes for lists of tasks that need to be done next. The notes stick to the whiteboard beside projects, so I can rotate work around. These are not detailed notes or TODOs, rather they are lists of key tasks that need to be done next, as well as notes from conversations and discussions related to the project.

When detail notations are required, I rely on formal specifications, issue tracking, and project management tools. These are the endpoints of the process, rather than the crux. This allows me to use tools that fit the job rather than forcing all problems into a single method.

The principles of business tools

What I’ve found is that there are a few simple principles that are critical for small business tools and processes.

Low cost and high utility are critical

Use physical constraints of real-world tools to your advantage

Use software only where it’s the best tool for the job

Single tools do not often fit all problems

I’ve seem businesses spend disproportionate amount of their profits on automation tools, processes, and other organizational objectives on systems that failed to deliver.

A set of tools should be grossly pragmatic, vastly improving profitability and quality. Anything less is irresponsible to the business and the businesses purpose.

]]>https://warpedvisions.org/2017/11/14/simple-methods-the-triage-board/feed/0636Linocut: lines and texturehttps://warpedvisions.org/2017/04/17/linocut-lines-and-texture/
https://warpedvisions.org/2017/04/17/linocut-lines-and-texture/#respondMon, 17 Apr 2017 21:53:32 +0000robotponyhttps://warpedvisions.org/?p=686I made a quick print this weekend based on a few drawings I was working on last week. The idea was to make a block print look like a sketch, and to use background lines as a textural element.

]]>https://warpedvisions.org/2017/04/17/linocut-lines-and-texture/feed/0686A design philosophy for 2015https://warpedvisions.org/2015/01/04/a-design-philosophy-for-2015/
https://warpedvisions.org/2015/01/04/a-design-philosophy-for-2015/#respondSun, 04 Jan 2015 00:27:25 +0000robotponyhttp://w28.warpedvisions.org/?p=116A friend asked me what my design philosophy was and how it had changed over the years. He was asking about the design and flow of applications and websites. Actually, he actually asked about visual design specifically, which I found interesting in itself.

I paused for a moment when he asked, which is unusual for me as I’m normally quick to answer questions about myself. It’s a big question, in that he was looking for both my current opinion and how my perspective has changed. It was more than that though, as he was also begging the question of “What is design?”

He clarified his question by adding that he wanted to understand what I thought was good design and good design practices, which led to a discussion with many examples and clarifications. We talked about how websites like Reddit.com could have great content yet such a visually appalling, awkward, and dense experience. He initially wondered if visual design was the crux of my philosophy, but I told him it was more than that. Aesthetic can further a site with a better or more focused experience, but the visuals do not stand on their own.

We talked a bit about I what I thought design was terms of the overall experience, including information design, content flow, information modelling, and aesthetic. I think his perception hinted that I’ve talked a lot more about the visual aspects of design in the past and less about the other factors. I likely have too, as I am most inspired by things that look great, and that inspiration is something I talk about. Things that flow and function well, while still inspiring, are less obvious and are things I speak about less passionately.

We talked through more examples, each of which I found helped to remind me what I had learned and where my mind had explored. I tend to forget how long a journey it has been, that other people haven’t seen what I have, and that I haven’t seen what they have either.

It was a great question. It made me think about design from a different perspective, considering where I’ve been and how I’ve travelled. It also made me admit that I had not been writing about design, something I should be doing much more of.

So what have I learned in 2014?

Focus and content is something that was missing on the web, in web applications, and in software in general. Luckily we have seen this change in the last few years. I believe focus to be the most important shift in the design of content and applications in general, as well as a narrow, more vertical scope.

Applications and content improve as unnecessary things are removed. As things are pared away, applications become more tightly focused on whatever their core truth is. Focused writing applications are one example of this, or narrow publications like Serious Eats, or simplified presentation mechanisms like the presentation of content in Medium.com. Single serving sites are another example of narrower approaches (doing one thing well, often focusing presentation and limiting the scope of what they provide). Focus, on all axes, is paramount to better experiences.

Grammar and standards are something I’ve talked a lot about over the years, but recently I have become more comfortable with my position. Both grammar and content standards are a fundamental part of content design and experience. This covers things like post title formats (e.g., sentence case, tabloid case, AP case, etc.), citation formats, callout conventions, and so on. There are many documented standards that we should look to first when designing content and applications that use metaphors from written and printed materials. Ignoring these standards reduces the overall experience in many applications and websites.

More importantly, these standards provide free and comprehensible design. Many people already know what a citation looks like, for example. Following a standard format communicates citation-ness for free. Using one particular format for citations communicates even more, it also reflects the flavour of the standard and its history.

Typography and document layout standards are something I have been studying more recently. This is another aspect to the design of content that is well-solved, where applications and websites are often ignorant of rules of thumb and practices that have been tested over many centuries.

Combining grammar, writing standards, and typography provide ranges of colour that reflect different, specific meanings. These palettes of meaning can be used intentionally in design to reflect different qualities in the content presentation. For example, using tabloid case for headlines and colloquial grammar with a relaxed (sans-serif) style body font can be used to suggest content that is more down-to-earth or provincial. Content presented with Oxford rules, classic serif body fonts, and classic styling screams academic. Realizing the meaning communicated by the various stylings and that there are standard styling mechanics, is something that I’ve known about for a while but only recently been using together as a larger design brush.

Skeuomorphism versus minimalism are application design principles we have seen in applications and websites over the past few years. The trend has mostly been a movement away from the literal metaphors to simpler constructs (and then back a bit again).

Apple, for example, used very literal constructs for applications in early versions of iOS and OS X. There were aspects of this that were good, but it (in the opinion of many) lacked tact and style. More recently, Apple dialled the literal back to zero resulting in a very minimalist set of applications and constructs. Google followed a similar path, but they stopped short of zero, coming up with a design language with concrete (but still abstract) metaphors. Understanding these extremes, their history, and effect is important.

There are aspects of skeuomorphism that are important. The idea that concrete objects deliver a familiar and intuitive base understanding is a useful design tool. It is interesting (though somewhat obvious) that the completely-literal, over-the-top metaphors of earlier OS’s and applications felt off. And it is unsurprising that if you strip away too much of the concrete that the result can be confusing. The concrete and literal reflections of our world are important in software, and the balance is an significant factor in comprehension and comfort.

There are a number of anti-patterns that also help shape how I now think about design. These are simpler concepts that I find lead to poorer overall experiences and content.

Attack of the boilerplate (or death by template), for example, results when obvious technical implementations box content into shapes that work in some cases but not others. The best example of this is the blog post in both full and summarized forms. Blogging tools tend to use single representations for things as it is technically simple. There are many types of content and ways to present content, and templates will often force all things into a single format.

The best example of how a template format can degrade content is to compare Reddit and Digg versus Twitter (or the old TabDump/HackThePlanet). Reddit and Digg display all links and posts identically, including superfluous controls, links, and attributes. Twitter boils links down to a statement and link(s), in a more freeform manner. Both techniques are viable, but the latter is more focused and more pliable to different types of content.

Boilerplate-itus is also a problem in applications. User interface toolkits provide a set of tools that can often be used out of convenience and not based on what a problem deserves. Many video applications, for example, stick to tiny play controls in the bottom left of a video. It’s a tiny target for a mouse pointer (or finger), and is mostly the result of using what is already there. Is it good design? Probably not.

On the other end of the spectrum, the not-invented-here anti-pattern can be worse. Just take a look at Google applications on iOS. They feel out of place, breaking standards left and right. This isn’t always bad, but following the Google-Way ™ on another platform is an extreme that can also produce awkward experiences. My favourite example here is the Google YouTube application for iOS, which while functional, has a navigation system that is counter-productive on iOS.

Much of what we think in design is based on examples and the patterns these examples boil down to. The concept of examples and patterns is one of the strongest communication tools in design, as an example can communicate so much with so little effort.

And finally, information modelling and architecture is what I consider to be the starting point for good design. Finding the concrete ideas and constructs in a problem, mapping those to experience and flow, and using this underlying reality to select brushes from standard techniques like UI literalism, content, typography, is what design is to me. Know the landscape of the problem. Use the tools available, with knowledge of the tools together with your map of the landscape. There are many valid paths through a problem and the best ones are found with an honest understanding of it all.

I used to talk about this domain modelling by describing finding the underlying things. A thing is a thing, and finding these constructs and staying honest to them is critical to understanding a system. Unfortunately, using the word thing so frequently in talks and writing is confusing, so I’ve been searching for better ways to describe it. Really, I was looking for better ways to talk about affordances and domain models, terms the are more difficult to use in conversation than thing and object. Ultimately, I think landscape, paths, and tools are better metaphors to describe why things like affordances and models are needed.

Looking ahead

So I see design techniques as part of a set of tools that allow us to manufacture experiences and function. The techniques are often based on a history of knowledge and experience with resulting standards that we should understand, that if we ignore we are choosing a path of unfortunate ignorance. There are often multiple standard techniques, each with purpose and meaning. Realizing the value of these different approaches is important for finding better paths through the problems we design our ways through.

The techniques, however, are only the tools available to us. They are not design.

Things like information architecture and domain modelling are cartography techniques. The allow us to define and map the landscape of the problem, using various methods of dissection, diagraming, and documentation. These are also not the entirety of design, but rather the mapping part of the problem.

I see design as the mapping and tools we use to find a great path to solve a problem, where great is defined by things like, time, overall experience, appropriateness, safety, and so on. Design is pathfinding, which relies on mapping and the tools of our trade.

So where do I go next?

I will write more about the various aspects of design. I will continue to doodle, draw, and diagram my use of the standard techniques. And, I will build more, and write more about what I build, as design is only as useful as the projects that use it.

]]>https://warpedvisions.org/2015/01/04/a-design-philosophy-for-2015/feed/0116The art of code reviewhttps://warpedvisions.org/2013/07/30/the-art-of-code-review/
https://warpedvisions.org/2013/07/30/the-art-of-code-review/#respondTue, 30 Jul 2013 00:00:28 +0000robotponyhttp://w28.warpedvisions.org/?p=4I review a lot of code these days. It’s an incredible way to nudge a team of bright people toward greatness. It allows me to look at problems from the outside with a perspective of experience and distance from the low level design. The perspective is important too, and I see things that I often miss in my own code. You see, we’re easily blinded when we’re too close to the problems we’re trying to solve.

Think of it like this: walk up to the front of a large building. You won’t be able to see around it anymore: the roads leading away from it are obscured, and the metropolis surrounding it is dwarfed by its stature. Your perspective limits you.

Rule 0: no one has immunity

I require review for most code that comes from my teams, including my own. Github pull requests are a great tool for this, as you package up a change, relate it to a bunch of tracked issues, and open it up for peer review. It allows you and your team to comment, iterate, and accept or deny each patch. There are lots of other ways to do this, of course, but the mix of branching and discourse is brilliant.

Rule 1: reviewed code is always better code

You don’t have to review all of the code produced by your teams, but it is incredible value for the effort. It’s far easy to bump design and learning along in small steps, and far cheaper too. There are fewer surprises, fewer rewrites, and a much easier learning curve for everyone.

I can review code for a few teams of developers, given a mix of skills, in a few hours a day. That includes time to talk over issues with individuals and group whiteboard sessions. The code review leads to design review, and a solid understanding of where your teams stands on a daily basis. Getting the team productive gets you to shipping.

Rule 2: develop simple ways to sample code

Understanding every line of code is difficult, especially given the chaos that creeps into the daily life of a team lead. Even after taming the chaos you still need to find ways to focus on code in ways that finds the important holes. How do I do this? Simple heuristics, or in other words: rules for finding crap.

For example, when reviewing anything in Python, Ruby, Perl, or PHP, I look for programming conventions from other languages. Parsing strings using strpos? Is there a better way in the language? Is there a faster way? Is there a cleaner way? I call this: alien syndrome. It’s easy to spot, and even though it’s sometimes the best solution, it’s more often a sign of a developer who has failed to really understand the language. A sign that they’re limiting their thinking to what they know and not in the potential of the tool at hand.

Rule 3: write down your rules and philosophies

Write your rules and style guidelines down and share them with the team. Make them into manifestos or a top-$n list. Have fun with it.

Here’s my 8-bit list for reviewing code:

Alien syndrome – the code uses a convention or mechanism from a different style of language. C-isms in Python? That’s weird!

Exception litter – a function spreads its error cases throughout larger algorithms. Is the data unreliable? Failing early seems more humane than dragging it out.

In-and-out buggers – the code mixes generation with logic. Can the logic be split into something more easily tested? Can the generation be split into some sort of adapter or template?

Elbow-itis – the design or code has several elbows. Does the complexity of the code or design fit the complexity of the feature? Not!

Inconceivable – language or library functions used in odd ways, or where much better mechanisms are available with a bit of searching. Do the functions do what the developer thinks they mean to do? Various uses of regex are especially subject, as they represent incredibly dense logic.

Are we there yet? – algorithms or classes that drone on well past their welcome. What makes the code so lengthy? The rhythm of the code is much like prose: it should feel good, not boring.

How DRY I am – repeated code is stupid. I may be lazy, but testing something more than once is crazy talk. It’s also expensive and prone to errors on several levels. Bad mojo!

I add heuristics regularly, based on simple misconceptions, new techniques, or especially creative developers (often including myself). I focus on different types of problems with different developers, and with different types of designs.

Rule 4: review should use what people do best

Let the computers worry about syntax checking, enforcing persnickety grammar rules, and testing for large and complex things. Code review does not replace the compiler, the lint tools, the unit tests, the system tests, or the load tests. How could it?

I focus my time on things that I can use to teach better techniques, on patterns I can use to prevent entire classes of problems in the future. In the rare case where there are grievous basic issues, I call everyone to the bat cave.

Rule 5: to the bat cave!

Some problems deserve more than one-on-one time or group training. You know the type of problem I’m talking about: that API that’s warty and gross, or those SQL queries that are covered in slop. Picking these things apart piece by piece would be painful and cruel. Didn’t someone tell you not to pick at the scabby things? No?!

These loathsome problems require a graft and not just a simple nudge. Solve the problem properly, cleanly, and with some tact. No sense in making it painful or tedious. Write a standard or a guideline, and plan some real time to scour the grit out of the gunk. Fix it up right, and take the fix out of band to the mess it solves. No sense in dragging developers through the mud. Pick them up, set them straight, and show them how to solve the problem properly.

Rule 6: there is no rule 6

There are always problems that don’t fit your experience. Roll with it and remember your team is awesome. Support them, look for the long game, and base your recommendations on solid first principles and fact. Keep it clean. Keep it fun. And remember: code review is a form of programming itself. You’re encoding your team’s success using a simple series of feedback loops.

]]>https://warpedvisions.org/2013/07/30/the-art-of-code-review/feed/04Simple patterns: PHP to JavaScripthttps://warpedvisions.org/2013/07/25/simple-patterns-php-to-javascript/
https://warpedvisions.org/2013/07/25/simple-patterns-php-to-javascript/#respondThu, 25 Jul 2013 20:29:59 +0000robotponyhttp://w28.warpedvisions.org/?p=35You can pass data between the client and server in a number of ways. I like to mirror data structures between my server and client, so that I have the same basic data model available in both realms. There are a few ways to do this, including:

Calling an API that returns JSON (or JSONP)

Calling an API that returns some UI, which can include some JSON

Getting an entire page that includes your data model in JSON

Sending a client data is trivial in most dynamic languages, and PHP is no different. You return a response body with the result of a json_encode and your data model. The technique works just as well in APIs as it does in standard HTML templates:

The result is a mirror of your server side structure on the client. You should encode your object somewhere else (like in your framework), as you should take care to ensure that the result is valid, but the simplified example shows the basic process.

You can replace these data objects from the server in subsequent requests too, ether in JSON calls or when requesting subsequent chunks of HTML (by including the same script tag). The technique lets you keep your client and server model in sync, to whatever degree your application requires. It also helps force your thinking to data structures, which gives you a chance to properly model what your application needs.

]]>https://warpedvisions.org/2013/07/25/simple-patterns-php-to-javascript/feed/035Five things to love about PHPhttps://warpedvisions.org/2013/07/07/five-things-to-love-about-php/
https://warpedvisions.org/2013/07/07/five-things-to-love-about-php/#respondSun, 07 Jul 2013 20:29:59 +0000robotponyhttp://w28.warpedvisions.org/?p=34PHP is a great language. It follows a long lineage of C-based syntaxes, mirroring much of the C standard library. It performs well, is trivial to deploy, and has been stable for many years. And, it’s almost universally hated.

While many people look down on PHP, it’s worth considering where it shines compared to other languages. I find that in many uses, PHP provides a great set of features and elegance. Not only is it competent, but there are places where it is truly a great little tool.

But first, what’s up with the hate?

PHP is old

PHP has changed over the years. The result is a language specification that has (at times) been incompatible with previous versions. It also has produced a warty standard library, with a large variety of naming and programming conventions. I agree that this should be improved.

On the other hand, the current language is expressive, and the runtime libraries are vast and rich. Any good code editor will provide auto-complete (and API references). I’ve found PHP no more difficult to navigate than C, C++, Java, or Ruby, though I’ll agree that Ruby is a lot tidier.

Too much dynamite

Another common complaint has to do with PHP’s automatic dynamic type casting system and how it can be confusing. This stems from versions of PHP prior to 5, though there are still a few edges where the language can be used incorrectly to produce incorrect results. Namely, when comparing dynamic types, take care to read the documentation and use the appropriate casts and operators.

Library quality, thread safety, and so on

Other complaints include varying library quality (this is a problem in most of the languages I’ve used), and thread safety (also a common problem). These problems have never blocked anything I’ve used PHP for over the years, as I use it for problems it fits well.

There are also other language quirks that frustrate people, things like ternary behaviour, historic security issues, error handling, and so on. My assertion is that, yes, PHP is quirky, but no more so than Javascript or Perl (or many other languages). I find that PHP produces very readable, predictable code for a few specific problems. This makes it a great tool for those problems, despite the hate.

So what’s to love?

If you can get over the warts, there are many features in PHP that come together to make a solid set of template and API building tools. PHP is designed as a thin veneer over HTTP requests, with enough finesse to build simple, clean interfaces.

My favourite PHP features:

Dynamic class loading, allowing you to register your own loader for classes that are requested by code and not found in the current namespace. It makes it possible to handle installation errors nicely, dynamically create modules at runtime, or provide custom loading of nearly any sort.

Dynamic class accessors, a feature that allows you to provide class accessors with a single function, making it trivial to provide clean and consistent error messages with a minimum amount of code.

Dynamic call dispatching allows you to route class member calls through a single function. This makes it simple to provide a learning interface, one that can probe a remote API and dispatch based on the results. The syntax to the caller is clean, and it implements with only a single function point.

First order templates. PHP is a template language at its base. It allows you to represent output in the output’s format, hooking to the language with an obvious syntax. With its ability to set the variable namespace, it makes for a rich, performant template system.

HTTP/CGI at its base. PHP, when started by a web server, is primed and ready to go. No additional libraries are needed, and very little work is required to parse a request and produce a response. This makes it possible to service web service requests with minimal overhead (though oddly most PHP frameworks do not do so).

There is more to love too. PHP has a solid set of mechanisms for defining classes and namespaces. It provides interpolated strings and oldschool HEREDOCs. Many of its core features and libraries are implemented in C (and perform well). Given a reasonable amount of discipline it produces predictable, useful code … about the same amount of discipline required to work effectively in Javascript or Perl.

PHP isn’t for every problem. For example, I find that it’s a poor fit for shell tools (Bash, Perl, Ruby and Python are much nicer here). It also doesn’t scale to huge server side things on its own (Java? Ruby?). And it doesn’t have the rich ecosystem of things like Ruby and Rails. But, PHP is a solid tool in my kit, especially suited for lean web things.

It’s a good question too. It turns out the answer isn’t as simple as it should be. On principle the answer is, “No, it’s not cool”. A GET is an idempotent request for a resource. You don’t request a resource with a resource (what would that mean?), you request it with a resource identifier. The HTTP spec, however, is unclear on the subject and does not explicitly disallow it (it probably should).

This developer was using the request body as a convenient way to send a complex set of parameters, as JSON is much more useful to work with than URI encoded components. His approach was both sane and pragmatic. But, it was also incorrect.

Four reasons why you should avoid payloads GET requests

It’s unexpected. You are not guaranteed that all HTTP implementations will treat it in the same way.

The spec says so, sort of. Servers could/should ignore request bodies, as they have no semantic meaning to the request.

It doesn’t play nicely with caching. Many caching layers use the URI as the cache hash. Unless the URI is changing between requests, the payload will not change the result of the request.

It’s disingenuous. A GET request uses a URI to name the resource. The request body is irrelevant to that request.

Sometimes the simplest questions are not answered by the spec.

And how does the story end?

The developer recast the GET as a POST. The semantic of the request was to retrieve a customized resource based on specific parameters, essentially creating a new resource on the fly based on the given parameters. As the filters were non-trivial, they could not be cast as HTTP headers or components of the URI. This was a pragmatic fix too (one line in his tool chain).

Uncovering what a feature means is fundamental to the method. It exposes the nouns and verbs of the problem, and hints at the useful metaphors. The freeform nature of sketching and developing storyboards based on this language helps me focus on figuring out what the things mean, as well as finding their shape and rhythm. I end up working on several different approaches before it’s obvious which ones are workable for the client and product.

Moving to static and live mockups transforms these ideas into reality. I aim mockups to be as close to production quality as possible, as anything less distracts from thinking and the discussing the designs. These distractions are the worst sort too, derailing any shared thinking on how an interface should be.

The method is important. It’s worth practicing, and I do on a weekly basis (I’m always designing something).

Recent examples

I haven’t posted much ongoing design here, mostly as I haven’t been that proud of it (or haven’t been the primary designer on the projects). As my hone my craft, and as I work on more interesting projects, I will talk more about my work. This is a good thing.

Inline bar graphs.

This is part of an updated reporting project. I found that the bold graph elements and combined (and pivoted cell data) improved readability of the table. Realizing that different types of columns had vastly different visual needs (as they were different things) improved the clarity of the data overall.

Simplified application chrome.

The simplified application chrome is part of an ongoing improvement project. We’re reducing the size of the chrome (or bling), so that the guts of the application are much more prominent. The previous design had about 35% of the page dedicated to this chrome, which is now about 10% of the overall vertical space. We’ve hit the basic brand colours and shapes, improving the clarity of the product name itself and removing unneeded navigation.

Smaller, graphicless login.

I’ve also simplified the sign in form. Nothing revolutionary, but we’ve reduced the size and amount of noise significantly.

Learning is doing

This summer’s design projects reinforced a number of principles for me:

Process is bullshit. Method and practice, however, are crucial to execution and skill.

Hammering at the methodology and practicing each of the individual skills shows results quickly. I’m able to prototype a new set of features in a few days now, assuming functioning creative mojo. Iterating design with shorter design stints makes for more polish. Wax on, wax off, and all that.

]]>https://warpedvisions.org/2012/09/30/summer-design-fragments/feed/037Real work is boring (but I love it)https://warpedvisions.org/2011/12/24/real-work-is-boring-but-i-love-it/
https://warpedvisions.org/2011/12/24/real-work-is-boring-but-i-love-it/#respondSat, 24 Dec 2011 04:55:55 +0000robotponyhttp://w28.warpedvisions.org/?p=61I had an epiphany early this year: getting good at something isn’t about finding a groove or being especially clever, it’s about honing a method of doing something. Or lots of methods, meticulously crafted, carefully practiced, and well executed over and over again. That’s it.

The problem is in discovering the method. It’s harder than you expect.

It turns out that most things, while easier than you’d think, are much different than you’d expect. The process for making an excellent curry, for example, is nothing like what I had imagined, nor is the path to better photography, or art, or anything. Finding methods for things is in itself curious, and my methods for getting to good versions of things is always unexpected.

Software and web design are no different: they’re not difficult, but the path to become competent with them is nothing like what I dreamed when I was younger. I found that it’s mostly about discovering and repeating methods of doing the parts of design, and spending much more time polishing than seems intuitive. And while getting feedback can teach you something, curating your own design sense pays better returns. It’s all in good taste, practice, and polish. Seems simple, no?

A pattern emerges

Earlier this year I was thinking back on the various redesigns of this site. My approach to design has changed, as you would expect, but more interesting: it takes a lot longer now than it did 15 years ago. What I found was that design gets better the longer you polish it, and it becomes exponentially better the more times you’re able to distance yourself from it, which allows you to actually see your design as others might (and this is the real magic, the seeing).

The trick with design is in finding perspective, and taking the time to polish it. And many of the methods I use now exist explicitly to look at a design from different viewpoints. I had to discover these methods, practice them, and only after that could I start to produce even mildly competent designs.

With cooking I found that it was so much simpler than it looked. Basic flavours and layering techniques are incredibly similar around the world, the only differences are in the available ingredients and how you mutate the dish with heat. The hard parts of cooking are in mastering the most basic of skills, and in the preparation and timing. The actual cooking and inventing new dishes is as simple as adapting what everyone else is doing around the world.

Photography? It’s only two things: interesting composition and lots and lots of photographs. Everything else is bullshit. It took me years to realize that I would throw out most of my photographs, and that sometimes I would take a shitty shot and turn it into something interesting, and that if I didn’t that life would go on. And life does go on, and sometimes I impress people with that one picture that sits on a pile of garbage shots. And sometimes people like the shot that I think looks like shit.

And art? Art is one simple concept: make peace with failing over and over again, searching for that one thread of interesting. Once you find it, you obsess over the methods that got you there, repeating and varying it as much as you can. But the key is that you have to fail over and over again. Who expects that? And if you hear it, who believes it?

Unfortunately you have to discover the meta principle yourself. And fortunately these unexpected things are all related, as art, design, and life are all one thing.

The critical factor is that doing something well has an unexpected path. You might know what works well, as in you like that curry or that photograph–but doing it yourself means discovering some counterintuitive principles, and repeating them, practicing their constituent parts, and then cherishing the path that got you there. Over and over and over again.

]]>https://warpedvisions.org/2011/12/24/real-work-is-boring-but-i-love-it/feed/061The problem of organizationhttps://warpedvisions.org/2011/10/31/the-problem-of-organization/
https://warpedvisions.org/2011/10/31/the-problem-of-organization/#respondMon, 31 Oct 2011 04:55:56 +0000robotponyhttp://w28.warpedvisions.org/?p=62It’s not that these tools and techniques are bad in themselves, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be tidy, professional, and complete.

There are a few causes to the problem of organizational buildup. Our software is limited, our methods need improvement, and the unseen pieces of our project pile up and are left a mess once we ship.
categories: rants

TODO lists, project management software, and GTD all have the same basic problem. They push you to produce things that aren’t your end goal, to help you improve your focus, thinking, and (in the end) produce better quality software in less time. These artifacts clutter your archives; the very things that help you create more effectively get in the way. They’re a form of noise to your project’s signal.

It’s not that these tools and techniques are bad, but our use of each should be fit into a well tuned approach to building software. An entire project delivery should be useful, professional, and complete.

There are a few causes to the problem of organizational buildup. Our software is limited, our methods need improvement, and the unseen pieces of our project pile up and are left a mess once we ship.

Everything is a file

Our tools treat each of our artifacts as equal. They’re generic, as there are many approaches to managing projects, so very few assumptions are made about the importance of each piece of the process. Requirements, specifications, prototypes, estimates, and development plans are strongly interrelated, but few tools are able to capture this.

Even the application structure of project management and software development tools re-enforce the everything-is-equal by placing features in tabs, sections, and tree nodes similarly. While it’s easy to organize product features into tabs and tree nodes, it keeps them at the same level of importance by default and we have to work to tame the mess.

A polished specification is much more important than the research and prototypes that fed into it. A completed user interface design is superior to the sketches and feedback that improved it. Our tools, however, rarely help us focus on these differences.

Rushed and unfinished

Our own methodology–our process of analysis, design, and development–contributes to the chaos of project bits. We don’t like to fund (or spend time) on things that aren’t part of the output, so prototypes, design documents, and specifications remain unfinished and unpolished.

We also produce, and subsequently discard, various artifacts as we’re learning the process of building better software. These forays into improvement leave a wake of debris that is unlikely to be used again. This is a failing of team management and individual process: we just don’t put enough emphasis on picking successful tools or polishing and curating the prerequisites.

Projects need teams that have a winning approach. We should not be exploring process on project time (side quests are better for this), and hence the exploration and failure of various processes should be insulated from active work. Why practice at game time?

Cooks who cannot clean

Our tools should serve us better. Our own methodology should avoid processes that fail us. In the end, though, we shouldn’t leave the mess behind. Each member should take pride in what we deliver, including the parts unseen: the designs, specifications, drawings, models, and all the supporting pieces.

Our methods and techniques are not unfortunate side effects in building software. They are what’s involved in building software. We sketch, we design, we carefully consider each piece. These supporting activities are not lesser to writing code, they make writing code better.

Less is more

There are many great reasons to use better tools, to understand the process of building software, and to curate the entire effort. We know that it improves communication, reduces bug rates, and reduced project costs. We know that it makes for better software. And yet we end projects late, incomplete, insufficient, and in a mess.

Let go of the tools that do not work. Ignore the processes that are obvious losers. Obsess over ways of documenting design that take less time, and produce something useful. Learn to write better, make your sketches count, and don’t leave a mess at any time. The thinking that goes into your software is the software.

Know how to build software. Sketch, document, and plan. Be proud of the method of building software, and curate the in-between steps. Spend time between projects improving your process; finding ways to do less and better. And above all, curate your thinking and the things you record your thinking with. What you produce will be better for it.

]]>https://warpedvisions.org/2011/10/31/the-problem-of-organization/feed/062On becoming a designerhttps://warpedvisions.org/2011/07/06/on-becoming-a-designer/
https://warpedvisions.org/2011/07/06/on-becoming-a-designer/#respondWed, 06 Jul 2011 04:55:58 +0000robotponyhttp://w28.warpedvisions.org/?p=64I’ve become passionate about design. It’s a subtle craft that says something, things that can’t normally be said with words. It suggests things. It implores us to think in a particular way. It encourages us to go here or there. It is enough of a metaphor to be easily recognized, but not so much that it becomes tacky, unless of course tacky is the thing you need. Design is the artful side of craftsmanship, the soul of a thing.

I was talking about design the other day with a friend. “How do I get into design,” he asks? He already has the passion for design, he sees design, but he lacks the processes for finding, honing, and pushing designs along into to production.

How do you get into design? You need to see it first. Feel it. Then you do it. Again, and again, and again. Floundering, failing, and fumbling your way through at first. Is there any other way to learn to ride? To swim? It’s a craft that requires balance and grace, and some amount of time to learn to execute well. And that’s okay.

How do you get into design indeed! Find your passion, as it fuels the process. Passion is simple too: focus your frustration, awe, and excitement for a thing into a narrow band of optimism and spunk. It can always be better, and it can always be solved. It’s just a matter of seeing it, boiling it down, and then actually doing it.

Passion starts with comprehending that a thing isn’t working well enough. Then you imagine what it could be, what else has been done—what hasn’t been done yet—and let your mind iterate over the possibilities. You eat. You sleep. You shower. You read. And at some point you see it, as if it were magic.

You’ll see many visions of what it should be (many of them good). Later you’ll learn which visions are better, and which are worth chasing after. But find your passion first, then learn to listen to it, to ignore it when it’s wrong, and to trust it when it’s onto something.

An example

I love reading. Great inspiration can be found by streaming in the things other people write. Books are especially excellent, as the format turns out thoughtful, polished experiences. Buying and finding books, on the other hand, is something I often find frustrating. It’s an investment of time and money that can result in a growing pile of carefully bound recycling. Books you feel compelled to keep (but likely will never read to completion).

Now there are bookstores and libraries that make finding books a better experience. You know the sort, comfortable chairs, brilliant selection, and a staff that know the product and who love to read. These shops are gems.

Enter Amazon.com. It’s a store with incredible potential. A huge collection of titles. Reasonable shipping, easy book downloads, and a sturdy site to run it all. But it doesn’t work well and it’s not very inspiring.

My favourite book store isn’t much to look at, but it’s organization is incredible. The shelves were built by the owners in a way that showcases the right books, providing an archive for depth, all while being easy to navigate. The owners themselves are avid readers, having read most everything I’ve asked them about. They haven’t just read most of their inventory, they usually know exactly where it is or when they’ll get it in next. And if you want a recommendation, they remember what you’ve read so that their recommendations are only a few steps from clairvoyant.

Amazon isn’t much to look at either. In fact it’s downright noisy. Dozens of things mashed into every page, making it difficult to find what you want. While their selection of print books is excellent, many of the books are not available for download. The result is an experience that isn’t fun or inspiring. In fact, I often avoid it until I’m absolutely out of reading material.

Amazon could be so much more. It should be the comfy bookstore you want to browse. It should be the eclectic owners, their pristine organization, and the recommendations that leave you wondering if someone knows just a bit too much about you. It should be effortless, not leaving you wondering if something will be available for your mobile device in your region. It should feel like the perfect bookstore, melting away to trade your money for a lifelong experience of losing one’s self between the pages of whatever turns your crank.

But it isn’t. Buying books online is mostly worse than queuing up at your local mega mart, innundated with impulse items, inexperienced staff, and bright, over-saturated displays and lighting. Limp, uninspired, grating a bit on your nerves. You shop there when you have to, but the result is uninspired.

The first part of design describes that feeling, the way a thing should be front to back. The real world things it needs to bring to you, to make you feel. And the real bits of functionality that it absolutely must have.

The second part of design is in describing and making it happen, but that is something best talked about after digesting the first part. So go on, digest.

]]>https://warpedvisions.org/2011/07/06/on-becoming-a-designer/feed/064The evolution of thinking in software designhttps://warpedvisions.org/2011/06/10/the-evolution-of-thinking-in-software-design/
https://warpedvisions.org/2011/06/10/the-evolution-of-thinking-in-software-design/#respondFri, 10 Jun 2011 04:55:59 +0000robotponyhttp://w28.warpedvisions.org/?p=65I know a few generations of developers. I find they tend toward different ways of thinking about software design, based on the languages and decomposition tools that were available at the time they formed their thinking. Their tendencies shift over time too, but often their imaginations are limited by whichever mode of thought they’re working in at the time.

By design I mean the approach to solving a problem with software, including software architecture and low level design (not product, visual, or UX design). These are another universe around how we think about solving people’s problems with software, a topic for another set of posts.

I realized the other day that design thinking follows an evolutionary path. It progresses to solve larger problems in better ways, and is based on layering and combining the various tools and techniques available.

A maze of twisted pathways

Flowcharts and pseudo code

Data diagrams and relational algebra

Eventing and state diagrams

Object diagrams and trees

Layered architectures and approaches

Partitions and service maps

The thinking moves from direct low level constructs toward more abstract solutions, based on less obvious symmetries and fissures. A flowchart, for example, is a direct mapping of instructions. A set of services and domain partitions is far less direct, and often maps to important constrains like scaling, performance, and cost.

Well, duh

It’s obvious that our thinking has changed as software becomes more complex. What’s interesting is how we get stuck in particular ways of thinking, and how difficult it is to translate between the various design approaches. A procedural solution is a very different beast than one based on intersecting data, and is very different again from a set of disjoint services for the same concepts.

To talk about design intelligently, we need to lay the groundwork for how we plan to cast the approach. More than one design tool can be used, but it’s important that everyone participating in the design understands how to think and discuss things cast using that particular approach.

]]>https://warpedvisions.org/2011/06/10/the-evolution-of-thinking-in-software-design/feed/065HOWTO get better at stuffhttps://warpedvisions.org/2011/05/16/howto-get-better-at-stuff/
https://warpedvisions.org/2011/05/16/howto-get-better-at-stuff/#respondMon, 16 May 2011 04:55:59 +0000robotponyhttp://w28.warpedvisions.org/?p=66If you want to get better at something, do a lot of it. Throw yourself at practice and real chances to do it.

When you want to become great at something, stick with it, obsess over it, and suck up all of the knowledge that surrounds it.

And when you want to become truly incredible at something, you need to invert your thinking: reflect on the fundamentals, write, and do anything that lets you define what that thing is.

There is really no difference between a <div> and a <td>, except for the default layout settings and nesting. The major browsers support the distinction with the display: table-cell; and its important variants, so it’s a matter of how you want to organize your data.

The whole discourse ignores where the W3C is aiming HTML5, which is to use things like section, article, header, footer, and nav. These tags are much nicer than <div> or <td> soup, at least to me.

But screw semantics, you want your perfect little px layouts.

The complaint about pages that use positioned or floated blocks is the “difficulty” in rendering the classic column layouts. You know, the column layouts that don’t behave like newspapers (text doesn’t flow between columns). And guess what? These classic column layouts are based on—wait for it—the table layouts of the 1990s. HTML1, without any stinkin’ CSS. We did what we could then, with the tools we had.

Of course real column layouts are possible now with CSS3, where text and headlines can flow between proper columns, where you can control flow (roughly at least), and where you can make the columns look like real print columns. And reasonable faux-tabloid-sidebar-content-sidebar layouts are easy to build without table blocks, if you absolutely must have them, and you’re still free to use table block rendering if you’re so inclined.

But people want their pixel perfect, hey-look-I-can-use-Photoshop layouts, without having to work for it. These people miss the point of putting stuff in a browser, which is, “Hey, look, people can view this stuff in browsers of all sorts on hundreds of different hardware and software platforms!” You get a huge potential audience at the cost of easy pixel perfect layouts.

You can still churn out perfect layouts with all sorts of hacks and caveats, but the argument for putting things in tables is mostly unrelated. There are other ways to get the same effect, while making your content make sense to your future self and automated tools of all sorts. And there are better ways to get a good effect while supporting a wider range of browsers and tools. Fluid layouts are way more interesting anyway, as they work in more browsers, more usefully, and with less work.

Tables have their place, of course, for things that are actually tables of data. Even then, you could use paragraphs and headings if it made more sense for the content.

It ends up it’s all about the data. Make the data obvious, and everything else falls into place. HTML5 has enough semantic and layout expressiveness to wrap data in a way that is obvious and easy to make look good.

</rant>

]]>https://warpedvisions.org/2011/01/09/tables-versus-css-redux/feed/076Exposing designhttps://warpedvisions.org/2010/11/22/exposing-design/
https://warpedvisions.org/2010/11/22/exposing-design/#respondMon, 22 Nov 2010 05:14:40 +0000robotponyhttp://w28.warpedvisions.org/?p=79When you describe a design to a group of people, each person imagines something different. Depending on your story and the individuals, understanding may vary wildly. And if it differs enough, the result is chaotic–unpredictable and often negative.

You need to fit how you show your ideas to different groups of people carefully, and notice when you your story isn’t hitting. For your closest team members you can wave your hands and scrawl ideas on a chalkboard. For people you work less frequently, you need more detail: proper drawings and clean wireframes. For non-technical clients you need even more, polished, functional prototypes and pretty drawings.

When you fail to excite people with your ideas you do more harm than good. They imagine something more or less than what you’re thinking, leaving them disappointed and confused. You give them a different taste than you intended, which you will have to work to overcome in the future. Instead, you need to spark their imagination skillfully, stirring lively, constructive discussion.

A working example

One of the products I’m working on is a refresh for an ancient financial system. We’re working to make it scalable, easy to operate as a web service, and viable as a business for the client. Each of these problems is interesting and fun.

Early in our prototype work I made the mistake of leaking a technical proof to one of our non-technical team members (not the client, luckily). The prototype proved that we could reproduce the legacy calculations accurately, using cheap, common tools and schema design. Technically we were excited about the win, so we showed it around internally.

The problem with technical prototypes is that they lack pizzaz, often intentionally. This piece of the prototype matched the old system design to make it easy to test, but looked dated and out of place in a modern web app. The effect of showing this stage of the work to the wrong people bogged down our shared picture of the product. It killed our momentum and excitement, which took time and energy to recover. The loss was more psychological than literal, but was a cost nonetheless.

The next planned task, of course, was to find the visual styles for these screens, as now we knew that they were technically possible. And the design turned out better than expected, but the win was dulled by the lost momentum and our gains were smaller than they should have been.

More than words

The problem isn’t just in the explanation or the path, it’s in the combination of people, experience, and approach to the narrative. Each thing you show (and how you do it) matters. Each person’s understanding and contribution matters, as they are part of the momentum. Focus what you deliver, think clearly about the presentation, and keep your audience in mind.

There’s a bigger win in showing off the right work to the right people: it forces you to deliver better quality earlier. The risk and of miscommunication is real, and the wins–when you get them–are golden. Force yourself to show off better work, make it a personal goal. Challenge your team to show better work too. It pays off in a multiplicative way, and that’s good for the things you build.

]]>https://warpedvisions.org/2010/11/22/exposing-design/feed/079HOWTO: Directory recursion in Boost (and other tips)https://warpedvisions.org/2008/04/23/howto-directory-recursion-in-boost-and-other-tips/
https://warpedvisions.org/2008/04/23/howto-directory-recursion-in-boost-and-other-tips/#respondWed, 23 Apr 2008 23:22:50 +0000robotponyhttps://warpedvisions.org/?p=195Boost’s Filesystem library is an incredible library: it abstracts paths, directories, and stat results. It simplifies coding shell problems in C++, it’s portable, and is maintained by a large community of contributors. The one downside of Boost is that some of its newer libraries are poorly documented. ((Something I want to contribute to.)) Until I have time to get involved in the Boost project, I’m going to post examples here.

Traversing a directory tree

This is the coolest feature I’ve found in boost::filesystem so far. It treats directory elements like iterators, and has a convenience iterator that flattens the problem of iterating through a directory tree recursively. The only examples I found for it were in their extensive test sources, ((See convenience tests and operations tests for more examples.)) which are a bit light on comments.

The example starts in the current working directory, and prints all of the file names (and directories) in inode order. ((Later I’ll try to post an example that uses the stat features to dump extra information.))

Notes:

I don’t alias the namespace here (but I recommend doing so in production code, see below)

Creating an instance of recursive_directory_iterator sets it to the .end() element by default.