Today, I’d like to briefly introduce a project for Theravāda Buddhists. Buddhism, like most religions, have a few sacred texts to describe their teachings. One of these texts, the “Abhidhamma”, is rather elusive and complicated to understand. My dad has been teaching this difficult topic for the past 15 years, and over the past year and half, has written a 200-page introductory book for those who want to see what all the fuss is about. It’s chock-full of diagrams, references, and bad jokes.
To quote from the actual page: There are eight lessons in this course covering selected topics from the Abhidhamma that are most practical and relevant to daily life. Though it is called a “Practical Abhidhamma Course,” it is also a practical Dhamma course using themes from the Abhidhamma. The Dhamma and the Abhidhamma are not meant for abstract theorizing; they are meant for practical application. I hope you approach this course not only to learn new facts, but also to consider how you can improve yourself spiritually.
So, click to go ahead and learn about the Abhidhamma.
I had the pleasure of helping on various technical and visual aspects, and I’m happy to launch PracticalAbhidhamma.com which will serve the book as well as any future supplementary content. For those interested, the book was typeset with LaTeX, with diagrams provided by Inkscape with LaTeX rendering for text labels.
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
- irssi/quassel -> weechat + relay
- 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! :)