To quote the beginning of the full article: “This article explores different priorities of human comfort and how these priorities were satisfied in standalone artificial environments, such as space stations.“. If you’re impatient and just want to read the full article, click to read A history of design and human factors in Space Stations.
… or if you want a bit more background, read on …
I began investigating in more detail the field of space architecture last year. Although I had a bit of experience from the ISSDC, I was much more interested in real current designs as opposed to hypothetical scenarios.
Space architecture, and its parent field of design is a broad one. It’s an engineering challenge, an economic challenge, a logistical challenge, a political challenge, you name it. As an architect, the priorities of space station/settlement designs lie with the people that inhabit it. Simply put, you don’t call an architect to build a rocket, but when a person is living inside that rocket, especially if they’re stuck there for a while, that’s when you call your architect.
This means that when an architect looks at designing a space station, although they need to be aware of the technical constraints of the environment (gravity, air, temperature, structure, radiation, transport, health), their true expertise lies in understanding how to make people comfortable and productive within that space. This means that space architects need to understand to an incredible amount of detail how we perceive and are affected by our environment. Much more so than Earth architects, who have the advantage of the natural world, which is usually much nicer than whatever is indoors, as well as existing social and urban infrastructure. Space architects don’t have this benefit, and so the entire “world” is limited to what they can fit inside a large room.
This point: space architects are responsible for the happiness of humans, is an absolutely vital one, and unfortunately often missed. Too many architects are instead raptured by the technological pornography of the environment, the intricate constraints, or even the ideological ability to “reimagine our future”. No. The reality is much more humble: space architecture is about rediscovering what humans hold dear in the world. You cannot claim to reinvent a better future if you do not yet understand what we already appreciate in the present.
And so if my point has made any impact, please go ahead and read A history of design and human factors in Space Stations, where I walk through the history of space station designs, their priorities, and what architects are looking at now.
Cosy, isn’t it? Also, a TED Talk on How to go to space, without having to go to space shares many of my thoughts, and would be worth watching.
Note: the article was originally circulated on #cleancode and #kohana on Freenode and is now recorded here as an archive. It seems very useful as something to link people to on IRC when they have questions, so feel free to share as well.
At SevenStrokes, we practice Clean Code. Although code speaks louder than words, at the moment my public repositories are heavily outdated. What isn’t as outdated, however, is a short introductory guide I wrote on Clean Code for the internal use of SevenStrokes. Although it is a guide which focuses on the basics, it does make some assumptions on the reader having some knowledge about programming. You’ll notice that the examples are primarily written in PHP, but are applicable in all languages.
The article answers the question of why good code matters, what is good code, and covers the three pillars of good code: syntax, architecture, and workflow. It shows coding examples of how to write good code, introduces you to the more abstract architectural jargon, and different tools and processes out there.
Without further ado, please click to read: SevenStrokes: Learn how to write Good Code.
Note: extra comments here
It’s not often that I show my Blender artwork nowadays, but here’s three samples that I hope you’ll appreciate.
Oh look. A tree with a rock.
No wait. That’s not a rock. It’s a heart.
Yep, definitely a heart.
Those leaves aren’t right. What is it?
But wait, there’s more!
I’m pretty sure these are hands. Perhaps more than one.
Yeah, more than one.
How about something lighter?
I didn’t say this post would make sense :) But such is the nature of this type of artwork.
Yadda yadda yadda.
On Linux, there are things that you know are better but you don’t switch because you’re comfortable where you are. Here’s a list of the things I’ve changed the past year that I really should’ve done earlier.
- screen -> tmux
- apache -> nginx
- dropbox -> owncloud
- bash -> zsh
- bootstrapping vim-spf -> my own tailored and clean dotfiles
- phing -> make
- sahi -> selenium
- ! mpd -> mpd (oh why did I ever leave you)
- ! mutt -> mutt (everything else is severely broken)
- a lot of virtualbox instances -> crossbrowsertesting.com (much less hassle, with support for selenium too!)
… would be interested to know what else I could be missing out on! :)
So last year (or perhaps even the year before, time flies!) two people close to me participated in a friendly weight-loss competition. To do this, they used WeightRace.net.
WeightRace is a small web application I built a while ago for fun, which allows up to four contestants to compete towards a weight goal which they would set. They would be prompted daily for weight updates, and would set a reward for the winner. It also used some lightweight gamification so contestants could earn bonus “wobbly bits” when achieving things like their BMI.
But enough talking about the application — applications are boring! Much more interesting are results! Let’s see:
The two contestants — whom we shall refer to as Rob and Julie, which may or may not be their real name — and their results are shown in the graph above. Julie is red, Rob is blue, and their linear trajectories towards their weight goal is shown via the corresponding coloured dotted line.
If I could hear a sped-up commentary of the results, it would truly be exciting! Rob makes an excellent head-start well ahead of his trajectory, whereas Julie is having trouble beginning. As we near the holiday (Christmassy) season, we see Rob’s progress plateauing, whereas Julie gets her game on and updates with a rigorous discipline. Also great to notice is the regular upward hikes in Julie’s weight – those correspond with weekends! As the holidays pass, Rob makes gains and is unable to recover.
In the end, although Julie wins the Race, neither Julie or Rob met their weight goal (note that in terms of absolute figures, Rob actually wins). However, this was all not in vain. Given that almost another year has passed since this race finished, and I can see that Rob’s weight is now well under control and has indeed achieved his goal, I’d like to think that the WeightRace has played a role.
In particular, the WeightRace helped raise daily awareness. I believe that it was this daily awareness of the current weight that helped most in the long-term. In addition, the WeightRace helped Rob’s body to stabilise around 90kg for half a year! I suspect his body figured out that it could manage at that weight, which made it easier for him to (after the WeightRace) continue to lose weight at a healthy pace.
For those interested in playing with the WeightRace, you can check it out online at WeightRace.net. Note though that it is not actually complete, but works good enough for a competition. For those interested in the source, it’s up on my GitHub.