Igor Kromin |   Consultant. Coder. Blogger. Tinkerer. Gamer.

I wanted to put together a quick and easy kit so picked the Dr Who Tardis from the Metal Earth 3D Dr Who series of kits. Even though at first the kit looked very easy to put together there were a few places where I got stuck and spent quite a bit of time getting right. Overall it took about 1.5 hours to complete (I was expecting to be done in less than an hour!) It was a fun kit to assemble, and in the usual Metal Earth 3D way, it had it's own unique construction quirks.

Even though I am not a huge Dr Who fan, I quite liked the result...
DSC04215.JPG


This was a two sheet kit and was listed as moderate, though I'd probably rate it as easy-moderate myself. As expected for something that looks like a big box, there were quite a few large pieces in this kit. There were also a few of extremely small detail pieces, which took time to put together. The instructions that came with the kit were on a single piece of paper and there were no tools included. This was a flat pack kit, the usual for this size/complexity of model.

IMG_0689.jpg IMG_0688.jpg

IMG_0690.jpg


I used my usual selection of tools for assemble this model, including needle nose pliers (round tip and flat tip), scalpel, model making spatula tool, side cutters and of course a highlighter to mark off used pieces. The first part was to make the top chimney looking thing that sat atop the box. I don't think that I folded it quite right, but I could not work out any better way to to do it.
IMG_0691.jpg


Continue reading...  

, ,

I use the PHP Development Server for all of my local App Engine development work on my Mac and one of the features that's built into the app I'm working on at the moment is serving images. Out of the box this works just fine locally bar one small caveat - dynamic image resizing is not supported. If you do try and make use of image resizing, warnings like the following are displayed...
 GAE Dev Server Output
WARNING 2018-05-16 10:29:06,169 blob_image.py:208] Serving resized images requires a working Python "PIL" module. The image is served without resizing.


When deployed to App Engine it all works fine and this catch is explained in Google's documentation...
Note: When running your app locally on the development server, you'll need to install PIL if you wish to use the image sizing options described in this page.


Well no big deal, just install PIL right? Unfortunately at the time of writing there was no compiled version available for macOS and for the system Python version I was running. This meant I had to do a bit more work.

First I made sure of the Python version...
 Terminal
> python --version
Python 2.7.10


Alright, version 2.7, the only pre-compiled download I saw was for 2.5. I went ahead and got the source version of PIL 1.7. The following steps require Xcode and command line tools to be installed, I've already done this a long time ago, but here's a nice article that describes how to do it just in case.

I had a look at the README and got as far as the "If you're in a hurry" section...
--------------------------------------------------------------------
Build instructions (all platforms)
--------------------------------------------------------------------

For a list of changes in this release, see the CHANGES document.

0. If you're in a hurry, try this:

$ tar xvfz Imaging-1.1.7.tar.gz
$ cd Imaging-1.1.7
$ python setup.py install


Continue reading...  

, , , ,

I use iMovie on occasion to create time-lapse videos of circuit board assembly or putting together various model kits. For some reason my MacBook Pro just doesn't play well with iMovie whenever it is connected to my Samsung H890 USB-C Monitor. The monitor doesn't appear the be the problem because I was having the same issue with the Dell U3415W monitor I had earlier.

What is the issue? Well...iMovie opens and immediately crashes whenever my MacBook Pro is connected to an external monitor...
crash.png


Re-opening iMovie doesn't help, it just crashes over and over, as long as the external monitor is connected. Running it without an external monitor works fine.

I did manage to find a way of making it work with an external monitor however! Here are two videos, the first showing iMovie crashing when launched while connected to an external monitor. The second shows it working with my 'workaround'.



The workaround is quite simple...I just open my MacBook Pro so it's screen is active as well. When this is done, iMovie launches fine and I can then close my laptop again and keep working as usual.

It's a bit of an annoying workaround, but it works!

Continue reading...  

, , ,

I've been using simpleUpload.js as my uploader script for some time now and it's been great, bar one feature - error message display on upload failures. Because of its focus on compatibility with older browsers, simpleUpload.js tries to parse server response only when a 200-series HTTP code is present. This means that if you use, say a 500 error code, (as you should!) on failed upload process requests, you will get a generic 'Upload failed' message in the error handler.

Prior to version 1.1 this error message was more confusing - "Could not get response from server".

I contacted Michael about this behaviour in his script and suggested that he include an XHR object in the case of a failure so that client side code can try and extract a more friendly error message from the server (assuming one is returned). He agreed to make this change and I've been using it for well over a week and am very happy!
New in v.1.1: The xhr property is useful when the server returns with a non-200 HTTP error code on application error and you need to capture the server's error message. This isn't reliable in older browsers and the xhr property won't exist if there is a different type of error, but if an AJAX request was made and returns with a non-200 HTTP response code, you can expect this property. You should, in general, check for this property's existence before using it.


This example assumes that a JSON response is returned from the server side and that the HTTP response code is non-200 i.e. 500. This is the type of response that frameworks like Backbone.js tend to expect (which I've also been using quite heavily).

In my case, the response from the server can be boiled down to something like this (I actually return more data but that's not relevant for this example)...
 Error JSON Response
{
"error": "Some friendly error message"
}


The important point here is that there is a JSON object that has a property called "error".

Continue reading...  

, ,