This gallery contains 28 photos.
It is said that children would much rather play with the box than the contents. This works with cats too!
This gallery contains 28 photos.
It is said that children would much rather play with the box than the contents. This works with cats too!
I’m having trouble getting good photos of my desserts… they keep being eaten! Here’s another hard-to-photograph success; Cherry Ripe Cheesecake!
Makes a 25cm dia cheesecake
A: 375g good-quality chocolate biscuits
B: 125g butter, melted
C: 3tbsp cocoa (for chocoholics)
Process biscuits in a food processor until very fine. Mix in cocoa.
Add melted butter and stir together.
Line a spring-form tin with paper and press the mixture into the base and sides of the tin.
TIP: Pour about 2/3rds of the mixture in, and make the sides first! Then pour the rest in and flatten out a base.
Place in the fridge to set.
A: 200g dark chocolate
B: 4 large cherry ripe bars
C: 1 tin black cherries, drained
D: 750g cream cheese, at room temperature
E: 100g caster sugar
F: 3 eggs
Chop up chocolate and cherry ripe bars, place in a double boiler to melt.
Beat cream cheese and sugar together until smooth. Beat in eggs, one at a time.
Once chocolate has melted take it off the heat, and ensure it’s not too hot.
Beat in the chocolate mixture and cherries.
Pour the filling into the springform tin, and smooth out the top.
Bake at 180°C for 50 minutes.
Switch off the heat and prop the door very slightly ajar, let cool for 45 minutes.
Refrigerate for at least 3 hours.
A: 300g cherry jam
B: Cherry ripe bars, to decorate
Microwave jam in a heatproof bowl until liquid.
Pour evenly over cheesecake.
Chop or slice cherry ripe bars as desired, decorate top.
Place back in fridge for at least 5 minutes before serving.
Thanks to Hackvana, I’m making teeny tiny circuit boards!
No matter how good a board house’s process, there are some fundamental limits to how small things a board and the design on it can be.
A PCB is much easier to understand with a silkscreen! However, you can’t draw silkscreen lines narrower than a certain width, often about 5 mils. (Or 4 mils if you’re really lucky) So you’d better make sure none of your silkscreen is smaller, or lines will be spotty and text will be unreadable.
(Huh? What’s a mil? / One thousandth of an inch. / Okay. What’s an inch? / …)
With Eagle able to display line widths in mils, it’s not too difficult to check your lines.
What about text?
(How do I get mils? / Click on the Grid button in the upper left, and change the grid units to mils. You can change it back later)
Here is the text “ISP”, and the text attributes dialog.
Size is the height of one row of text.
Ratio is the text’s line width, as a percentage of size.
That’s fine. You’ll just need to make it thicker.
These are still a bit small…
This one is probably juuust thick enough. But the text is only half a millimetre high!
Good. 50 mils (1.27mm) or larger text is probably more sensible. If size is 50, and we need at least 5 mil silkscreen, then the ratio should be higher than 10%. Easy!
A board house will often tell you their dimension limits, for traces, isolation, and silkscreen.
For best results, avoid the limits.
If you can make your text 10 mil thick, and the board house can manage down to 5 mil, you should have no problems.
Left-over cream, what can I do with this? Cribbed a few recipes together, and improved the technique.
Salted Caramel Sauce
A. 500g caster sugar
B. 150mL water
C. 300ml double cream
D. 250g butter
E. 1 heaped tsp salt
Here’s my new very dangerous tart recipe.
Not for diabetics or those with heart conditions!
A. 250g plain flour, sifted
B. 3tbs cocoa powder, sifted
C. 3tbs pure icing sugar, sifted
D. 165g chilled unsalted butter, chopped
E. 30ml (2 tbsp) chilled water
A. 300g caster sugar
B. 180ml water
C. 250ml double cream
D. 120g salted peanuts, finely chopped
A. 150ml double cream
B. 150g dark chocolate, coarsely chopped
The tarts will be very rich. Serve with cream or ice-cream.
debugWIRE is a fantastic bit of technology in many recent AVR chips, allowing you to set breakpoints, step through your code, and a bunch of other useful features. All you need is a programmer that supports it – the AVR Dragon for instance.
In the Atmel Studio project, simply set the Debugger/Programmer Interface to debugWIRE.
The only fly in the ointment is that for extremely low-power applications, having the DWEN fuse and thus debugWIRE enabled will prevent the chip from fully sleeping, meaning your device is much more thirsty than expected.
So you set the Debugger/Programmer Interface back to ISP, and try to program your device again; Failure! In fact; CRYPTIC ERROR MESSAGE!
TO CLEAR debugWIRE FROM A CHIP WITHIN Atmel Studio 6:
Start a debug session on the chip, then
Go to the “Debug” menu and select “Disable debugWIRE and close”.
Now you can access the chip using ordinary ISP, and low-power devices will be more frugal.
This may seem an obvious thing, but there are a number of “solutions” floating around, including people advocating hooking HVPP programmers into devices simply to clear DWEN!
There was some concern about my previous solution, that it loads templates synchronously and serially. An application should have templates inlined before it goes to production anyway.
Fair point though, there is a better way.
Firstly; Marionette.js can transparently lazy-load and cache DOM-stored templates;
//What I had been doing var MyView1 = Marionette.ItemView.extend({ template: _.template( $("#template_myview1").html() ) }); //What I should have been doing var MyView2 = Marionette.ItemView.extend({ template: "#template_myview2" });
The difference between the two is significant.
This means the templates are only built at the time they are first used. The template blocks don’t need to be accessible at the time the classes are defined. The app only needs to build the template functions the first time they are used.
Using the MyView2 style will give much faster start-up times for larger applications.
(Marionette.TemplateCache can be used stand-alone, or you can fairly easily create your own caching DOM template loader)
Now, the template blocks won’t be referenced until they are used. We can load them asynchronously now, but we still don’t want to start the app until the templates have been fetched. $.ready(…) won’t wait for the templates, but there’s a fairly easy workaround;
//A list of promises that need to resolve before starting var loaded = []; //Load all templates var $templates = $('script[type="text/template"]'); $templates.each(function() { var src = $(this).attr("src"); if (src) { loaded.push( //Wait for the template to load $.ajax(src, {context:this}). done(function(data) { $(this).html(data); }) ); } }); //Wait for the DOM to be ready loaded.push($.ready); //Initialise after everything is loaded $.when.apply($,loaded).done(function() { //Start application });
There! With that in place;