For several years now, I have been using git as a means to manage migration of my website from one version of wordpress to the next. I initially was maintaining documentation for my self on how to do this manually, but later I migrated the documentation into an automatic script. I've decided to clean this up a bit and release it to the public as open source.
This has really made managing a wordpress site more bearable. I don't allow FTP connections to my website, since FTP is about as secure as a sign on your digital lawn saying "Please do not hack!" Because of this, the built-in automatic update feature has always been useless to me. Using an ssh connection to the webserver as the backbone, it's possible to do more secure automatic updates than built-in feature can provide. (For more info on security, please read Hardening WordPress.) In addition, I can sleep better at night since my website's code is both version-controlled and backed up to an external server. This isn't possible with the traditional "update wordpress via svn" method either.
Hopefully this will be as useful to you as it was to me. I've tried to make it reasonably configurable, but feel free to fork it and tweak to taste. You can find the code and documentation for wp-upgrade on Github.
I've been working a lot with Unity3D recently, and sometimes it can come in handy to have multiple instances of the editor open at once. On Mac, this works fine, but due to how the dock works, it's awkward to launch more than one instance, requiring you to root around in the app bundle and have a terminal window open.
I wanted a quick shortcut to spawn a new instance, so I threw together a shell script and bundled it up as a stand-alone Mac app using Platypus.
If you're interested, you can download Unispawn on Github. It's not really worthy of its own name and an icon, but I couldn't resist making some references and I needed it to look different from Unity in my dock.
All 3 lines of its source code are available under an MIT license.
GDC is over and I'm hanging out at Noisebridge with some friends. I've been inspired this week by some amazing Twine games and authors so I decided to make a short one myself. It feels most like a poem to me.
I just finished playing Christine Love's Analogue: A Hate Story. I would like to share with you my thoughts on the design, themes, and ramifications of the game, hopefully without revealing many plot or character details that could spoil the experience.
Analogue was a remarkable game that stirred up a wide range of emotions. I felt repulsion at the backwards, patriarchal society depicted. Shock, the traumatic kind, at the depiction of horrific events. Sympathy and affection for the protagonist (at least, that's who she was in my view.) And some funny, cute, and adorably awkward moments as well. It was quite unlike the expectations I had for the game going in. It was deeper, more meaningful, more significant.
Processing is a wonderful little language. It's designed to be easy to pick up by artists who want to learn some programming, etc. However, it's a real programming language. If you haven't played with Processing, I'd recommend you go do that right now. They have a great series of tutorials, and of course the entire SDK is free.
This post is for people like me - programmers who want to take advantage of Processing's short iteration cycle, clear syntax, and simple API to use it as a prototyping environment.
First, here is what I think Processing excels at:
Interactivity - It's dead easy to get and use mouse and keyboard input and define event handlers.
Engineering flow - like I said above, the short iteration cycle, clear syntax, and simple API make it a breeze to get up and running quickly and iterating.
Fun - Because of all of that, it's a lot of fun to write stuff in Processing, especially for smaller projects where you are just messing around.
Multiplatform - Out of the box, Processing 1.5 can build native applications for Windows, Mac, and Linux, native Android applications, and web applets (yuck.) Via Proccessing.js you can also supposedly get your sketches to run natively in web browsers.
Here is what I think Processing is weak at:
Large, complex programs (they tend to get a bit unwieldy since it's impossible to organize your classes inside a folder structure.)
Programmer assistance (No out-of-the-box debugger. The preprocessor's errors are often frustratingly non-specific, and can leave you blindly hunting for syntax errors across multiple files.)
Audio (there is no out-of-the-box support, but there are libraries available) Processing now includes the excellent Minim library, but you have to explicitly import it. Audio still appears to be an afterthought in the documentation and tutorials.
I have been prototyping games and visualizers (including the one above) in Processing for several months now, and have learned some incredibly useful things that I think any programmer looking into it should know. Here they are:
For many people, it really doesn't make a difference. But I'm a programmer. I edit code for a living. My editor is the tool of my trade and I want to use the most efficient tool available.
I'd be preaching to the choir if I was telling programmers that they should use good text editors. But I've noticed some patterns in the history of text editors I've used that have made me come up with my own philosophy about choosing an editor. My goals and usage habits are certainly not the same as everyone else's, but I hope that in sharing them I might get you to reflect on your own habits and see if they match up to your goals.
The find utility is so useful for automation that it deserves a special mention on its own. I will not attempt to cover all of its features, only the ones that I use on a daily basis.
I typically use find for two purposes:
To create a list of files matching some search terms.
To execute a batch operation on those files using the -exec argument.
In Shell Scripting: Becoming a Wizard, I layed out a recipe for productive and useful bash scripts that uses a while loop over some sort of multi-line input. This construct is more powerful than find's built in -exec flag, but that power is not always needed.
I'd like to show off some projects of mine that are currently on the back burner, to avoid them from gathering too much dust.
Here is a video of a game prototype I was working on in UDK. My idea is to express the feeling of being in zero gravity in a way that hasn't been done in games before (i.e. no jetpack.) You move by pushing yourself along surfaces and kicking off them towards other surfaces. Once airborne, you can't alter your velocity without grabbing on or bumping in to something (or possibly throwing stuff out of your pockets.) I hope someday to make a real game from this concept.
I reflect on this prototype, why it went to the back burner, and what I learned after the jump.
I was fortunate to get several chances to play Nidhogg at GDC 11. I'd like to share my first impressions of the game.
Nidhogg is a brilliant fighting game for two players created by Messhoff (Mark Essen.)
I suck at most fighting games, although I have a lot of respect for the people that play them. Watching my old roomate Kilo play Super Smash Bros. Melee and BlazBlue and talking with him about it helped me to understand the deep nature of these games. So did the excellent documentary I Got Next. Key to these games is the idea of a metagame, and playing mindgames with your opponent, occurring on different layers of anticipating your opponent, called yomi. Check out David Sirlin's excellent article for an explanation of the layers of yomi in mindgames. The basic idea is that you have a certain set of moves, some of which can be used to counter others. Some provide a greater reward (more damage, a stun, etc.) but at higher risk. Some are lower reward but also lower risk (low damage, shielding, etc.) Effectively mindgaming your opponent relies on knowing what your opponent thinks you will do, and playing off those expectations. A noob will try to use his most powerful move at all times if he knows how good it is, but this move is risky, so a pro will know that and counter it. But if a pro is playing another pro, he might also use the powerful move, precisely because the other player wouldn't expect him to since it's typically too risky.
Sirlin's game Kongai did an excellent job of bringing these mindgames to a wider audience by removing the need for the millisecond reflexes that pro fighting game players must have, following in the vein of stuff like the battle game from Pokemon.
Nidhogg has accomplished something fantastic, in that it retains the real-time thrill of a classic fighting game, but provides a relatively small amount of actions that the player can take, which makes the game easier to pick up and play for the average gamer without having to learn a bunch of different combos for each character. However, the design is elegant, as these moves are more than enough to create interesting mindgames.