Gruber Motors had a terrible fire over the weekend that started with a faulty building electrical panel, and lost 30+ first generation Tesla Roadsters. There were so few Roadsters made (around 2,450) that such a loss is not inconsequential & could represent 2% or more of all remaining Tesla Roadsters on Earth (assuming others have been totaled/scrapped for other reasons over the years- and some definitely have).
I found out about this sad news today and it made me wonder if there could be a way to improve the odds when things like this happen. Lithium Ion batteries fires are notoriously hard/impossible to extinguish once battery packs are ignited, and for a unique company like Gruber Motors who service and repair these older Roadsters, the chances of fire spreading from vehicle to vehicle to a catastrophic end have unfortunately proven to be high (this is their second fire in about 4 years). I thought of a few ideas including some kind of in-floor conveyor belt system to help separate or force cars apart quickly, but none of that seemed very practical.
Events like this remind me of the importance of developing less volatile battery technologies, like solid state.
Here's a list of all firmware updates through Feb. 8, 2020.
I just traversed 26 NYC blocks on a stand-up electric scooter carrying this 20+ pound Casitone 403 keyboard over my shoulder in an Ikea bag. Feels like I just completed some weird urban olympic event, but instead of a medal I got an analog drum box with stylish wood grain! Fair enough.
This is my attempt to future-proof a tutorial process for updating Flash Pro CS6. My hope is that this guide can work for the next several versions of the Flash Player. In this example I’m moving up from Flash Player 17 to version 18.
This method may work with Flash Pro CC or Flash Pro 5.5 as well (I’m not running those versions, but let me know if you try it). At the time I wrote this up I was running Windows 7, but this process may also work on Windows 8 or 10 (let me know if you try!)
Dropped by the Laptop Music Production workshop at the Hacker Dojo in Mountain View earlier this week.
What a great forum. Folks took turns playing original tracks, sharing their mixes via projector, and discussing all sorts of music & production-y things. I myself pulled out a track from four years ago- time to finish that one I think.
Tracks by some of the artists present that night:
It’s hard to have a blog called “Rock The Machines” and not mention it when Captured! By Robots plays a gig in your back yard (well, not literally in my back yard, though that would have been cool.)
JBOT, the reluctant but obedient leader/servant of the seminal Bay Area “one-man-plus-angry-robots” band played the last show of his 43-city tour at Benders Bar this weekend.
I have fond memories of CBR playing the Bottom of the Hill many years ago. The robots have evolved over time, but still seem to be plenty angry- and just as determined rock their creepy, humanoid faces off. Pulling off a live one-man show like this takes a lot of effort, planning & ingenuity.
John Vanderslice opened up his SF studio, Tiny Telephone, for their 17th anniversary.
Props to him for opening his studio to the public, providing free beer, and delicious food! What a cool place.
Thanks also goes to Steve Beck for inviting me along!
Below are a few photos I took of some of the the treasures within.
Defect Reports are a new thing Ebay introduced as part of their 2014 Spring Seller update.
The report format can be tough to view in it’s native format (a text-based .csv file).
I created a web based viewer to feed your report into and get a much better sense of what’s what. Lots of folks from all over the world have used the tool & found it helpful. If you’re a seller maybe you will too!
Here’s a link to it: http://thinkspring.net/tools/ebay/defect_report_viewer/
Also, a video on how to use the tool:
It’s safe to say that there have been issues regarding AIR’s graphical performance on the original Nexus 10.
I have seen several examples where content works flawlessly everywhere else- or at least across the dozen or so iOS/Android phones & tablets I normally test with. But when it comes to the Nexus 10, there have been issues– either with or without employing Stage3D.
I have had a long standing issue with one app in particular, where a short keyframed animation containing mostly bitmaps drags the app’s framerate down as low as 1fps. It even slowed down the rate that frames were logged in Scout CC, which I’m not sure I’ve ever seen before. At any rate (ha!), I wanted to share the one “dead-simple” thing I found that changed everything.
Short answer: there was a vector graphic in the mix.
It’s easy to hear that and think “ah, well of course that was the issue!” But remember- this was a complete non-issue on every other device (including the original iPad, iPad 2, iPod4, iPhone 4, Android Nexus 7, Toshiba Thrive, Droid Incredible 1/2, Galaxy S3, etc.). On those devices, the vector graphic animated as quickly as everything else- offering no clue that it might be a culprit.
On the Nexus 10, caching that one vector graphic as a bitmap solved everything instantly- causing the brief, single keyframed sequence in my app to go from 1 fps back up to the 60 fps range.
If I had to make a guess, it would be that the Nexus 10’s above average resolution may somehow be contributing to the fact that what would normally be a slightly cpu-taxing task- moving some vectors around via math- becomes a huge burden in the case of (only) the Nexus 10. It’s a mystery, but I feel lucky to have been able to at least resolve it for my own apps & hope this helps someone else.