cd techblog git fetch git merge | grep "Already" > /dev/null || jbake
18 October 2016
The First Transistor Radio hit the market on this day (18 October) in 1954. (Read that in the voice of Garrison Keillor.)
Learning this today reminded me of one of my first pieces of electronics as a kid. It was a little blue, portable transistor AM radio that took 2 AA batteries. I got it as a prize from the school fundraiser, and I specifically remember it being listed as a transistor radio, like that was something special. I’m not sure how special that really was in around 1985, since we’d evidently had the technology readily available since 1954.
That radio was packed full of components on a board in its blue plastic shell. From the first time I had to open it to put batteries in it, I was intrigued by it — solder joints, variable capacitor, capacitors, resistors, transistors, antenna coil with ferrous core, bits of glue holding it together, etc. That thing came apart many times as I compared its contents to other devices and to those on my electronics kit later.
12 February 2016
The kids got a little M3D Micro for Christmas, and so started our adventures into 3D printing.
I intended to let the kids learn the whole thing from scratch, but I knew I was throwing them a little bit of a curve ball by only having Linux netbooks to drive it, so I ended up getting a headstart setting up OctoPrint and the M3D-Fio driver.
At the end of December 2015 when I was starting, the M3D-Fio driver had some configurations in the repository that might not have been optimal, so I was fighting a bit with a few problems:
adhesion to the bed
gaps and lines in the bottom layers
other quality issues
I thrashed around for quite some time changing settings I didn’t really understand, and Matthew spent a night helping me and showing me what his much larger printer could do — that helped immensely, since it gave me some hints as to what I should be expecting from my printer. I also learned what the different settings should be doing for me.
For an entire Sunday, about 18 hours, I printed 1cm test cubes and experimented with settings. I quickly decided I should have my settings and profiles tracked in my own local git repository, so I can always rollback to previous settings.
After a week or so, some updates from the M3D-Fio repository brought us more success with more default settings that matched the defaults found in the original software from Micro. The conservative settings also added rafts and slowed down the print a bit.
I was able to take those conservative settings and speed them up a bit and remove the rafts — the BuildTak holds a print pretty well even without the raft. I based my customizations on the stock profile that prints at 0.25mm layer thickness to get even more speed out of the printer.
I also found keeping a -0.4mm bed offset on my printer helped get just enough squish in the first layer to help get a more solid bottom layre and good adhesion to the bed.
Another notable configuration tip I had picked up was to set the wall thickness to a multiple of the nozzle size. In the case of the M3D, the nozzle thickness is 0.35mm, so I’m using a thickness of 0.70mm. Before I had learned that, a couple of my initial chachkies came out with thin gaps where the slicer should have decided to fill.
I’m at the point now that I have pretty reasonable expectations for what the printer can do, and I can start up the machine after a week or 2 of sitting, and run a print through reliably without needing to make adjustments. That’s great for letting the kids just make whatever they want. Both kids have been able to get into Tinkercad and produce some printable designs. Ben’s doing Nerf rail accessories, and Marie is designing a new cap for my growler.
Finally, I’ve pushed my configurations to a public git repository to serve as reference for anyone else who cares.
An update added a slicker settings dialog to allow more intuitive adjustments to a profile, so I’ve been testing relatively successfully with using the stock PLA profile and just flipping options. I did find that using a raft in "medium quality" mode fused my little 10mm test cube to the raft in a way that I can’t remove it. I usually avoid the raft anyway, though, since it sticks so well to the buildtak already.
05 January 2016
I’ve moved the blog to a static site generated by JBake. The source for the content lives in my techblog project in Github, so I have a full versioning of my content for the small price of a git workflow.
I installed JBake using the familiar SDKMan that I already use to manage my Grails and Groovy installations. I initialized it with the Groovy templating engine and have started customizing the templates.
To make sure this thing is easy to update, I keep a local clone of the repo, so I can update it any time and push whenever I’m ready. I have a shell script scheduled to run on the server which basically does:
cd techblog git fetch git merge | grep "Already" > /dev/null || jbake
That little bit of code only runs
jbake if the
git pull doesn’t say "Already up-to-date". That provided me a simple little "continuous integration" hook that polls git for changes to trigger the build. I’ll probably use this trick in other places.
I brought all my old content from my old database into the new platform using a quick little Groovy script to dump out an HTML file for each article including the header of metadata for JBake’s use. While most of these old articles will remain HTML, I intend to use AsciiDoctor format for all the new stuff.
I’ve been collecting a long list of (mostly technical) articles to write, but replacing the old platform kept trumping my attempts to write. Hopefully, this move can open the flood gates, and eventually, I’ll break out another instance of it for the photography blog. JBake should make it easy and interesting to continue the blogs.
16 November 2012
I've had my Nexus S for about a year and a half now, and I was stuck on an old stock Android for a long time—the AT&T version of this phone just never got the updates, so Matt helped me out and got me started with CM9 on the device back in the Spring.
Since getting some experience rooting and romming, I've tracked CM9, tried CM10, loaded stock Android 4.0 and 4.1. I found my device with stock 4.1 with my usual loaded apps (like BeyondPod, Tasker, etc) to be a little light on RAM. BeyondPod kept getting pushed out of memory when, really, it's my #1 app for daily use.
I needed to free up some memory, so I figured SlimBean would be worth a look. It seems to be based on AOSP with some of the most useful features of other ROMs merged, like notification toggles, etc. It's also relatively easy to install, though the upgrades keep recommending a full wipe and reinstall, which can be inconvenient, even with a ROM Toolbox doing my backup and restore of applications.
One of the most notable features is that the default DPI is set low (182ppi), so everything ends up tiny. Couple that with a tighter grid-size in Hololauncher and you can cram lots of app icons and widgets on the screen. I at one point bumped it back up to 200 to get it just a little more readable, but in the latest install, I've just been leaving it set to the default.
Amazon Appstore offered me my first problem. ROM Toolbox half restored it, but not the whole way, so it had some data files laying around but not the rest of the app. When I went to install it again from APK, it kept telling me "App is not installed". I finally figured out in this last time I wiped and installed, that I needed to delete the Appstore's data directory in Root Browser, and then it happily installed.
In the end, I'm not sure I gained much free memory—it still seems tight, and applications are still quick to get pushed out. I think what's slim about the ROM, is that it merged in some select features from CM and others without taking up as much space for everything those other ROMs offer. I like this ROM, and I hope to see it make Android 4.2.x and later available on my little Nexus S.