I have spent way too much time trying to figure out how to automatically have
modified_by be foreign keys to the current user, without mucking with every view and form. Every example I could find that told me how to do this, including django’s documentation itself, told me I had to customise every view and form, which I found to be rather un-DRY.
stealing borrowing some code from django-audit-log (in order to be threadsafe) I figured out how to update these values on any model that has them, without any fiddling with forms or views. I might wrap this up in a little project, but for now, here’s the gist.
Note that you should set
editable=False on your
modified_by fields so that they will not otherwise show up in forms.
If anyone is really interested i could wrap this in a self-installable package.
Notes to myself so I can set things up properly. Hope they’re useful to you as well.
- Install any OS Updates.
- Get XCode from the app store. Launch it, accept the license, and go to Preferences, then choose “Downloads”, and install Command Line Tools.
- Install XQuartz.
- Install Homebrew:
ruby <(curl -fsSkL raw.github.com/mxcl/homebrew/go)
- Install git from homebrew (
brew install git).
- Install Tower.
- Install Sublime Text.
- If you need subversion, install it from homebrew. If you need to use java, make sure you pass the –java flag.
You’re pretty much set at this point. Special per-dev type notes below: Continue reading
For my own edification and to facilitate the addition of UUIDs to Drupal, I have used SchemaSpy to create an overview of Drupal’s database schema as generated by today’s HEAD.
I have begun my quest to convert Drupal over to using UUIDs instead of IDs so that merging/branching drupal databases will be easier.
The first thing to figure out is how best to generate UUIDs in PHP. The naive pure-php approaches that use rand() have quickly proven to be non-viable (generating 10 of them hasn’t completed after several minutes), at least on my test virtual machine, presumably on account of running out of randomness.
The OSSP UUID module for PHP5 is much better, generating 60k “type 4” (completely random) uuids per second. However, the memory usage grows the more UUIDs you generate, so that could be an issue. So despite the fact that this module implies a C module that has to be available to PHP, I’m going to use it.
I will try to keep my implementation open to creating UUIDs in the DB, as PostgreSQL uses the same library to create UUIDs, so no sense in reinventing the wheel. MySQL UUIDs are broken in any sort of replicated environment (in that you can get the same UUID repeatedly from a given
SELECT UUID();) so I must have a language-level version available.
So now that I’ve elected to settle on the OSSP UUID module, I can take the next steps towards making it work in Drupal.
So I’m working on a steampunk-ish game that occurs in a gas giant – usual “colonization effort gone bad, descendants with primitive tech” sort of situation, except these folk actually have to stay afloat lest they be crushed to death by the pressure.
- Humans can live at up to 60bar for at least a week; presumably, if you didn’t need to decompress them, they could live much longer.
- Pressurizing quickly without changing the percentage oxygen is a recipe for dizziness, convulsion, and death.
- Long term exposure to high pressure can cause bone death. Not clear whether this is on account of the lower % oxygen necessary or on account of the subjects being de/repressurized.
- The clouds in a gas giant are quite possibly much akin to the atmosphere above 18th century london; full of soot, tarry particles, and metallized hydrocarbons. This is apparently on account of convection, precipitation, and evaporation, and ofc works better the hotter the gas giant.
- Deeper layers (and potentially different bands) would see the precipitation of some pretty spiffy molecules, including diamond, apparently; good reason to risk your life “diving”.
- While I have yet to find a really good excuse for a layer or band of CO2 enriched atmosphere, were there to be one, it could be much akin to venus’ atmosphere, including the sulfuric acid clouds. Soot filled sulfuric acid clouds sounds lovely, doesn’t it?
- Looking into diving bells, I realized that if the colony ship was a big (think km in diameter) concave bell-shape (used to catch the light from solar-system based lasers until the Bussard ramjet can take over) then when the ship has to “land” in the the gas giant, it can serve as a giant diving bell containing enough O2 enriched atmosphere for a small city. Since the rocket nozzle would have to withstand hydrogen plasma accelerated to nearly the speed of light, it would be robust against at least a few bar of pressure.
- Since victorian tech is not too good with the whole membrane thing, the kind of Scuba-style apparatus you’d need to hang out outside is kind of off-limits. If I posit some sort of mutualist parasite that provides O2 in exchange for nutrients, then I have an easy way of differentiating the “working class” from the elites who get to live in a controlled atmosphere their whole lives – it makes the infected literally “outsiders”.
I’m very spoiled by the virtual interface feature of Linux, and routinely have quite a few IP addresses associated with one virtual interface.
I’m building a cluster now, where all the machines have only private interfaces save one; obviously, I’d like the internal machines to be able to do their own updating, etc.
So I need to put in some sort of NAT. The problem is, iptables doesn’t recognize virtual interfaces, so you can’t NAT using the source/dest interface as your trigger. So here, then, is the simplest way I’ve found to set up SNAT on a virtual interface, assuming all your IP addresses are on eth0 and you are using a 10 network (in the example, 10.23.0.x) as your internal network:
cat 1 > /proc/sys/net/ipv4/ip_forward
iptables --table nat --append POSTROUTING -d !10.23.0.0/24 -j MASQUERADE