Probably for indykid…
Jul20
Confirmation on Sean Bean in Game of Thrones…
http://grrm.livejournal.com/95840.html
Along with Mark Addy as King Robert…
Confirmation on Sean Bean in Game of Thrones…
http://grrm.livejournal.com/95840.html
Along with Mark Addy as King Robert…
So, two weeks in the land of cheese and wine.
After struggling down the Gorge de Galamus in a wetsuit, climbing up above the clouds to revisit Peyrepertuse (and into the fog for Montsegur), trailing down into the bowels of the earth for the Grotte de Niaux and the 14000 year-old paintings, driving through thick night-time fog with no roadmarkings on the way back from Andorra, swimming in the lakes at Montbel and Puivert, relaxing in the hot springs at Ax-les-Thermes, standing goggle-eyed outside the incredible Fortress of Ultimate Evil which is Amiens Cathedral…
I’m back to find the boiler isn’t working, the roofer hasn’t arrived, it’s raining, and I’ve got a pile this long *gestures* of things to do.
Bah.
Edit:
So by 4.30 today, my day has consisted of:
- The boiler not working (and the plumber being on holiday ’til the 27th)
- The roofer not turning up
- HSBC telling my my credit card has been used fraudulently
- 6 inches of water in the floor of my car (dodgy doorseal)
- And at least three other irritating things that I can’t discuss publicly.
Double bah! Or even triple…
I had an annoying issue yesterday where I discovered that if I called Flash’s print function (via PrintJob) in a full screen AIR app the print dialog wouldn’t be shown – it would appear behind the main app window.
Took a bit of hunting around, but eventually I discovered that it was a simple case of setting:
alwaysInFront=false;
on the main AIR window (my main WindowedApplication).
Why it should have been set to true by default I have no idea.
Thought this might be useful for other people!
P.S. As an addendum, Flash/AIR still has major issues while printing, all to do with windowing and the print dialog. In the end we just couldn’t get it to work acceptably in full screen – so now when you print from our app we have to switch out of full screen, present the print dialog and then switch back in. Very irritating, with no native Flash/AIR workarounds.
It’s been a long time since I posted here – mostly because of the death of Friday Snippets.
But I have been up to some writing-related nonsense, so I suppose it’s a good idea to set some of it down:
All this and running a technology company, too!
Mysteriously, our book seems to have turned up on Amazon.com.
Which is nice, if surprising.
Although, given that it’s targeted at UK English speakers, it might have made more sense for it to be on Amazon’s UK site…
Excellent weekend.
Sai and Caroline hitched without a hitch… if you see what I mean. And completely undampened by the damp, except physically.
(I’m sure blokes are supposed to be unaffected by wedding ceremonies. *sniff* No, no – hayfever, honest.)
I still have bits of Andi and Juliet’s song bouncing round my head. (Not, not that song, scrofula!)
And all plans and schemes seemed to work out fine.
Really good to see everyone…
Extensive piccies from greatbigshowoff when the dust has settled…
I’ve been up to quite a lot at work over the last couple of months. It’s not finished yet, but I’m quite proud of the progress, and wanted to document it somewhere.
Our build systems were already substantially automated. All our new Flash-based projects have been moved over to the Flex command-line compiler wrapped with Ant (we used to use MTASC in the same way). And the final ‘publish’ bit was also done with Ant (turn the produced .SWF into an .EXE, or an Air file, or a Mac .app). So everything was already command-line, on each developer’s machine (the whole shebang in SVN to keep things in sync).
But we’re ramping up for a new style of delivery. Previously, because we’re working in quite a backwards market, we’ve been delivering on CD-ROM. We are still going to do that, but we’re also going to be delivering the same content on-line in a number of different formats – AIR (our preferred option), .exe and .app (for those who aren’t allowed to install AIR), and SCORM-compatible .zip at the very least. That’s a pain to manage and publish.
Under the old regime, the developer working on the project would have had to clean-and-build-for-distribution 4 times (for the four different formats) to produce the final packaged products – in some cases 4 times per language. Which takes a helluva long time. And then would have to FTP or SCP the lot up to a server, and update a website with the new details etc… and some of those build cycles weren’t that simple (moving to a Mac for the final Mac DMG, hand-building Windows icons for the .exe, hand-building Mac icons for the Mac .app, and so forth).
So I’ve been building a new build server to help us out in a number of ways. Here’s what I’ve managed to get going over the last couple of months:
All of which means that, to release a product to the public, a developer goes to a web interface and clicks ‘build’. Everything gets built and uploaded to a central repository, the developer gets an email saying whether it’s succeeded or not. Then the developer chooses which channels to publish it into, and bingo, people have instant access.
I am happy with this. There’s a lot more work to do yet (on things like authenticated downloading, watermarking/serialnumbering downloads, and a whole new website to go alongside it all) but the structure is there.
Added to that we’ve also got out of it a couple of really useful tools for the production team, including a string/resources editor that any of our content authors can use – which lets them modify (in a protected way) the actual resource files the developers are using – and a module documentation system.
All of this achieved with a Mac Mini (for the Mac-specific DMG building and .ICNS building), a Dell server, PHP, Java, Ant, Cruise Control (which we’ve hijacked and are just using as a queuing system), Code Igniter, SVN, haXe and, of course, the Flex compiler.
Nice.