Monday, March 15, 2010

Gitosis Remote Repository Cheat Sheet

I've found myself looking up how to do various operations on remote gitosis repositories recently, so I decided to create myself a cheat sheet. My remote repositories are on Debian systems, so the users and other configuration options are those that you get when you do a stock install of gitosis on a Debian system. Most of this is shamelessly stolen from Garry Dolley's “Hosting Git repositories, The Easy (and Secure) Way” with slight adaptations for the Debian differences. The idea is to cover the specific commands you need to deal with Debian remote gitosis repositories. This intentially doesn't cover anything that you can figure out from just doing “man git” and digging in.

Creating a new local repository from a remote repository

There is a remote repository that you don't have locally, and you want to get a copy to work on.

git clone gitosis@<server>:<repository>.git
cd <repository>

Note that the admin repository is gitosis-admin.

Setting up the remote origin on a new (non-clone) local repository

You are creating a new repository on the remote server. You have edited the gitosis-admin configuration files appropriately and pushed the changes, and performed

git init

on the local directory to create a new local repository, but the remote and local repositories are not yet connected.

git remote add origin gitosis@<server>:<repository>.git

Pushing a new local repository to the remote repository for the first time

I must admit this command seems more complicated than it should need to be. But at least you only need to do this once per repository.

git push origin master:refs/heads/master

Updated 2012-07-30: yes, it is too complicated. For some time I've been using this shorter version:

git push origin master

Sunday, March 14, 2010

Understanding ApplicationDomains

I've been explaining how ApplicationDomains work in ActionScript frequently in recent days, so I'd
thought I'd put down an explanation here.

ApplicationDomains contain ActionScript class definitions.[1] The rules for ApplicationDomains are:

  1. Every ApplicationDomain except for the system ApplicationDomain has a parent ApplicationDomain, so ApplicationDomains form a tree structure.
  2. Definitions in parent ApplicationDomains are used over definitions in child ApplicationDomains.
  3. In a particular ApplicationDomain, the “first definition in” is used.

The Flash runtime has a special ApplicationDomain called the System ApplicationDomain, and it is special for two reasons: it contains all the definitions that are built into the Flash runtime, and it is the only ApplicationDomain that doesn’t have a parent. All other ApplicationDomains are descendants of the system ApplicationDomain. This means that the classes that are built-in to the Flash runtime will always win over classes defined in swf files loaded by the runtime.

When a swf is loaded, all the class definitions go into a particular ApplicationDomain. For the main[2] swf of an application, the Flash runtime creates a new ApplicationDomain that is a child of the system ApplicationDomain. When the application loads other swfs, it can choose the ApplicationDomain that the swf will be loaded into.

Ok, too many words, time for a demo:

This application visually shows how ApplicationDomains affect which version of a class is instantiated, when there are multiple versions of a class present. The tree shown corresponds to the ApplicationDomain hierarchy created by this application: each ellipse corresponds to an ApplicationDomain. When you hover over an ellipse, six small coloured ellipses appear, corresponding to one of six different swfs. Clicking on a small ellipse will load the swf corresponding to the small ellipse into the ApplicationDomain corresponding to the large ellipse, drawing an instance of the class on that large ellipse. The six swfs all contain the same Ellipse class, but each version draws the ellipse in a different colour. This is the ellipse class:

    import flash.display.Sprite;

    public class Ellipse extends Sprite
        public function Ellipse()
            addEventListener(Event.ADDED_TO_STAGE, addedToStageHandler);
        private function addedToStageHandler(event:Event):void
            removeEventListener(Event.ADDED_TO_STAGE, addedToStageHandler);
            graphics.drawEllipse(0, 0, 50, 25);

The important part to note is the ELLIPSE::COLOUR constant. We create six different versions of this class by simply compiling the class six times, defining the constant differently each time:

mxmlc -define=ELLIPSE::COLOUR,0xff0000 -default-size 50 25 -o=ellipse-r.swf
mxmlc -define=ELLIPSE::COLOUR,0x00ff00 -default-size 50 25 -o=ellipse-g.swf
mxmlc -define=ELLIPSE::COLOUR,0x0000ff -default-size 50 25 -o=ellipse-b.swf
mxmlc -define=ELLIPSE::COLOUR,0x00ffff -default-size 50 25 -o=ellipse-c.swf
mxmlc -define=ELLIPSE::COLOUR,0xff00ff -default-size 50 25 -o=ellipse-m.swf
mxmlc -define=ELLIPSE::COLOUR,0xffff00 -default-size 50 25 -o=ellipse-y.swf

So to see the rules mentioned at the start in action, click the yellow ellipse in ApplicationDomain 111. That ellipse will turn yellow, because ellipse-y.swf, containing the yellow version of Ellipse, was loaded into ApplicationDomain 111 and an instance of Ellipse was created in that ApplicationDomain and drawn on the large ellipse. Then click the red ellipse in ApplicationDomain 1; this will load ellipse-r.swf into ApplicationDomain 1 and draw an instance from that ApplicationDomain on that ellipse. Click the small yellow ellipse (or any other ellipse) in ApplicationDomain 112 and it will turn red. Why? Since the red version of Ellipse was loaded into an ancestor domain, the new instantiations of Ellipse in ApplicationDomain 112 will be of the red version and any Ellipse versions loaded into ApplicationDomain 112 will be ignored.

To compile the main application from source:

mxmlc -o=ad-example.swf

I compiled these examples with the Flex 3.5 SDK.

  1. Technically, all varieties of ActionScript definitions are looked up via ApplicationDomains, not just class definitions.
  2. The swf referenced in the <object> tag of the html wrapper for a web application or the swf specified in the <content> tag of the application descriptor for an Air application.

Thursday, March 11, 2010

Thawte Privacy Breach?

I just received a snail mail notice from Thawte indicating that I have certificates that are up for renewal. Now, I do have certificates from Thawte, so I assumed that the notice was about one of those... but I was thinking, I don't have any certificates expiring soon, do I?

Then I opened the letter. It did, indeed, indicate that two web server certificates, specified by domain name and order number, were up for renewal in April and May. But they aren't my domains. If I were a malicious person, I could probably contact Thawte and, armed with the domain name, order number, certificate type, and expiry date, get access to mess with the accounts: change the password, get the certificate revoked, etc.

And of course, having received information for other people, I have to wonder, who has received mine?

Sunday, February 28, 2010

Hello World

Following the long geek tradition of self-referential names, I was tempted to call this blog Yet Another Technology Blog. But that's been done to death and YATB isn't particularly pronounceable.

And then I thought about calling it Mark's Standards, Technology, Unknowns, Practicalities, Innovation, and Design blog. That's quite a mouthful, but it can conveniently be abbreviated to “Mark's STUPID blog”. But that doesn't work because I fully expect that some of my entries will be beyond STUPID. At least in retrospect.

Finally I realized that my topics frequently come from someone popping their head through my door with “Uhm, Mark?”, and so the title of this blog was born.

In this blog I'll talk about, well, whatever I feel like, but it will mostly be technology-centric, from the social aspects of technology consumption and production to design and coding.