Comment This was foretold in song (Score 1) 123
Everything's Up to Date in Kansas City. They've gone about as 'fur as they can go - Rodgers and Hammerstein got it right!
Everything's Up to Date in Kansas City. They've gone about as 'fur as they can go - Rodgers and Hammerstein got it right!
The GP has been reading too much Crichton. Crichton goes to great lengths to describe the plane/engine relationship in that book (page 116 or so).
...strong winds and shifting shifts...
You really gotta watch those shifting shifts.
What are the worst practices that impede developers' productivity?
#1: Reading slashdot.
Remember that this initiative was out of the UK originally and was aimed at turbocharging the CS curriculum at the University of Cambridge’s Computer Laboratory. I'm amazed they've done as well as they have in the US given they didn't get FCC certification until April 2012; literally minutes before they went on sale.
I ordered 5 from newark.com on November 17th. They were shipped on Nov 27th. Three were defective - I RMA'd them on Jan 7th and got the replacement ones (which were all ok - whew!) a 3-4 days later.
From their website: "7200 Expected to ship 6 Feb, 2013". When I ordered mine they were backordered until Dec 26th, but mine came early. I assume their estimate is worst-case.
Go ahead and order some - they won't charge your card until they ship, so you're not out anything. I know one thing for sure - you won't get any unless you bite the bullet and order some!
Fireflies Bring Us Brighter LEDs
A band of ingenious fireflies, in a fit of magnanimity, decided to bestow upon us mere mortals the gift of their superior LED technology. Down they flew from their mountaintop aerie, each carrying a pair of Super-Ultra-Bright (tm) Firefly-made LEDs in their little firefly feet, and upon reaching Belgium, they lightly dropped them into the hands of grateful research scientists.
Simple, non-technical solution: Refuse to rely on a foreign source for materials deemed critical to the nation. Maintain your own production capability even when buying a cheaper foreign product (and stockpile if you must), but don't let your domestic production capability falter.
I think they've done remarkably well considering this was a shoestring operation from the start and they only expected to sell 10k units. I think they've dealt with a 100x increase in demand fairly well.
I've done the visual beacon ID thing a few times. My CW skills are fairly poor, so sometimes that's the best way for me to ID a beacon.
You know about the CW skimmers, right? They digitize a chunk of spectrum, decode all the CW CQ's and callsigns and report them up to the mother ship. Sometimes helpful, oft abused.
I thought of another use, too. I'd like to have it monitor 50.250-50.280 or so for FSK441 meteor scatter signals. The possibilities are endless!
B. something that actually gathers the raw data.
I love and use that site and am subscribed to get alerts. The problem is that I get alerts for openings where I can't hear anything as well as no alert when there's an opening I can use. If I scan the SSB portions of those bands, I can tell when there's an opening at my QTH, and maybe even include an audio snippet in the email. I could also include what stations the cluster 'heard' in the freq that popped my local squelch. If I wanted to have my house look like a Navy ship, I could use a constantly-rotating antenna and include the azimuth of the signal. (or 'rotate' the antenna electronically; hummm......)
Curse duplicate articles - I always end up posting in the wrong one. In that post you'll see a couple of things I use them for. I also plan on making a sporadic-E monitor for 6m, 2m, and 70cm amateur bands. That way it can ping me when there's DX afoot.
They are very cool and surprisingly capable. I had an initial bad experience (3 of 5 ordered from Newark were toast - the USB and ethernet would fail after several minutes), but they quickly replaced them with 3 good ones. I assume there was a bad batch in there somewhere.
It runs XBMC very well, and streams 1080 H.264 video just fine. I've also successfully used an RPi to decode ADSB transmissions from overhead aircraft using this software and an el-cheapo USB TV dongle. That's no small feat - the radio is pumping 2 Msps into that little fruity beast, and it's decoding them just fine. If you're curious, here's the source to the decoder app.
Haven't they ever heard of Beware the Ides of March ? This will not end well, I fear.
Aren't those cunning linguists clever? The answer always seems to be right on the tip of their tongue. They don't diddle around. They seem to be able to lick any problem.
Unless you are coding for 16-bit and smaller devices, those differences are negligible for getting your code to work.
Incorrect. Endian-ness is always an issue when working with structs, unions, or bitfields. I recently worked on a chunk of code that dealt with bit fields in a structure. Naively one would define it like:
typedef struct {
unsigned short bitfield1 : 3;
unsigned short bitfield2 : 5;
etc...
The behavior of bitfields with regard to endian-ness is UNDEFINED! You're probably too young to remember the mess that endianness caused with IP addresses stored in ints. Those tasty 4 octets fit perfectly into an int (everyone assumed) and they were always stored big-endian. NOT! When 386-based unix came along all of the networking structs and netmask routines had to be changed, and things like htons had to be created.
Part of the portability problem is that C is so close to the bare metal. The other part is that the C language spec is horribly weak when it comes to handling architectural differences. The only reason code works at all across platforms of differing endianness is due to kludges and workarounds.
Having said all that, I do like C a lot. Not as much as Java, though.
There are two ways to write error-free programs; only the third one works.
