Way before the internet made the idea plausible, Sony was ripping optical drives out of laptops to make them as portable as possible. One such computer, the $1,500 Sony VAIO PCG-SRX99 (circa 2001), weighed just 2.76lbs and made do with a 10-inch screen.

Inside, it had plenty of power, an 850MHz Pentium III-M, 256MB of RAM, and 802.11b for wireless networking (if you could find a wireless network, that is). Plus it had 20GB of storage, FireWire and even one USB port.

(I'd mention that it ran XP, but that part is a bit too familiar for nostalgic comfort.)

Today, the closest analog to the PCG-SRX99 is a netbook. For about $300 and a weight just shy of 3lbs, you can score a system that, from the outside, is remarkably similar. And on the inside, its clock speed has about doubled, plus there's anywhere between 4x and 8x the amount of RAM and storage.

But if you were willing to look a bit beyond skin deep, I'd argue that the contemporary smartphone is more similar to the PCG-SRX99 than the netbooks of today. Take the iPhone 3GS. In terms of sheer tech specs, it's pretty much a midrange smartphone...and it's about identical to our retro Vaio.

The 3GS has a 600MHz processor and an identical amount of RAM to the PCG-SRX99—256MB. And it holds anywhere from 16 to 32GB in flash storage. Amenities like Wi-Fi (faster 802.11g). Turn to a company like HTC, and you can double the RAM while including a processor as fast as 1GHz.

Still, while Sony's Vaio PCG-SRX99 couldn't fit in our pocket, we've championed its form in an entire wave of cheap, portable computers today. Oh, and that whole ditching the optical drive idea? Sony spotted that trend a mile away. [Product Page and Review]

Whereas uranium is extremely rare, requires purification and creates waste that will be with us for hundreds of thousands of years, thorium is extremely common, burns more efficiently in reactors and leaves less, less radioactive waste (that can't be turned into a nuke).

In fact, if it weren't for the Soviet Union building uranium reactors in the 60s (and us responding in typical Cold War fashion), we'd probably be using thorium today.

But as Wired explains, thorium may be poised for a comeback. [Wired and Image]

Its full details will be shared with us next week at CES, but the system will consist of a hardware scanner and a corresponding app. So while the iPhone's API restrictions will prevent you from scanning your card directly into Safari for your next web purchase, there are surely some remote pay possibilities in the works similar to what we've seen from Square—not to mention, it'll pave the way for an entire generation of even lazier credit card theft. [Pocket-Lint via SlashGear]

(Click the image for a large popout version.)

Of course, for those who don't appreciate the festivity of the ball drop, despite all of the hard work behind the scenes, feel free to ignore the ball's 32,256 glimmering Philips LEDs and turn your attention to your iPhone...because, yes, Waterford has made an app for that.

Happy New Year everyone!

"For years I lived with a wretched handicap," [name withheld] explained. "My hands were human-like and only a little bit cute, which is a tough thing for a model."

After fifteen years of transplant lists, fundraisers and miracle cures, she'd almost given up. Then researchers from Tokyo University of Science called and said they'd nearly perfected a new technique of removing a non-anesthetized kitten's paws with a rusty hacksaw and gluing them to the patient's wrists.

"The news was a Godsend," she said.

Given the slightest surgical mistake, a small, defenseless kitten would bleed to death quite slowly and painfully on the operating table. The human subject, however, would be completely unharmed, resting peacefully unaware of any blood or shrieking.

"Let's just say it's good that a humane society leases the space next door," said one scientist. "A really, really big humane society just filled to the brim with unloved strays."

As for the young model, she woke from surgery with a slight hand ache requiring nothing more than a prescription for a minor anti-inflammatory. And according to her official press statement, she couldn't be more pleased:

"Now my hands are very cute!" [Thanko via CrunchGear]

Last week, we had to can the results because only 3 photos were entered into the contest. 3! (The week before, we had almost 60.) So once again, please help me keep this section going strong—nothing makes me happier than seeing Gizmodo transition to cover not just press releases for gadgets, but the artistic products that said gadgets actually help produce.

The rules:

1. Submissions need to be your own.
2. Photos need to be taken the week of the contest. (No portfolio linking or it spoils the "challenge" part.)
3. Explain, briefly, the equipment, settings and technique used to snag the shot.
4. Email submissions to contests@gizmodo.com.
5. Include 800px image AND something wallpaper sized in email.

Send your best entries by Sunday at 6PM Eastern to contests@gizmodo.com with "Happy New Year" in the subject line. Save your files as JPGs or GIFs at 800 pixels wide and larger, and use a FirstnameLastname.jpg naming convention using whatever name you want to be credited with. Include your shooting summary (camera, lens, ISO, etc) in the body of the email. [Photo by Bubba Trout]

The Color Dial Spray is a refillable spray can design that contains all four base colors of the CMYK spectrum (cyan, magenta, yellow, and key black). When the artist rotates hue and brightness dials, the can tweaks the color mix accordingly, making selecting a paint color in real life just as easy as it is in Photoshop.

While perfectly plausible, the Color Dial Spray is still just a concept. But to any fat cat VCs in the audience, COME ON. What better ideas are floating around to sink money into? Social networking? Flying cars? Send these nice people a check. [reddot via Yanko Design]

As NewScientist observes, less than 10% of the world is more than two days away from a major city using ground-based travel. That stat only jumps to 20% when scaled to the Amazon, where river and expanding road networks have made even jungle terrain semi-assessable.

Also, nobody fucks with the cold climates.

On one hand, the map is a testament to human advancement and expansion. On the other, well, there are a buncha roads in what was once pristine jungle. (Yeah, I saw Avatar twice.) [Flickr and NewScientist via Neatorama]

Ping pong—a sport as un-American as Walmart apple pie.

Really nice, Ryan. Though for the drawer, I might have gone with dueling pistols and some sterile gauze. I know, I know. Everyone's a potentially psychotic critic. [Table&Tennis via Core77]

First, a little background. Yesterday, I posted about my second yellow-tinted iMac. And I made this threat:

I basically mail back review products for a living, and the joy of this new toy has long been spoiled. So I'm going to do my damndest to bankrupt Apple with return shipping. I will send back these iMacs as many times as it takes for them to build one correctly. And every single time that they screw it up, I'm going to air their dirty laundry here. Feel free to read it or don't. It's my opinion that Apple's cyclical production issues can't be swept under the rug any longer.

Shortly thereafter, a mid-level Apple representative who'd been handling my claim called (in alleged response to an email I'd sent before my post, not the post itself). I was informed that the company would not issue me another exchange straight from the factory. I'd, instead, need to get the iMac repaired at an Apple Store, lest I "want to waste the time and have to do this all over again." That's right, she basically admitted that everything coming off the line would be inflicted with the same disease.

I attempted calling technical support on my own for a second time to facilitate a true iMac exchange. After giving the technician my case number, they went off the line for about 5 minutes. And when they came back, my exchange was blocked again. This technician added that, following an exchange, "It's quite likely the issue will continue to happen...and that we'll become stuck in an endless loop."

Maybe she meant "infinite loop."

Call me paranoid, but I believe it to be true: Yesterday, after posting my threat, Apple tracked down my non-Gizmodo email I used to purchase the iMac and flagged my account to block exchanges. Either way, my hands are completely tied. Luckily, yours are not.

If my conspiracy thesis is correct, we've hit a nerve with Apple. So I'm only going to increase my efforts with your help until they publicize and/or fix the yellow LCD issue. Here's what I could use from you:

Anyone out there who's in the process of exchanging an iMac for one without a jaundiced screen and receives a replacement January 1st or after, email submissionsATgizmodo.com to let us know if the issue has been resolved. New purchases that turn out to be yellow are great as well. Please be sure to:

1. Use the subject "Yellow iMac"
2. Take photos of this screen test (just make sure to lock that white balance!)
3. Include details like the ship date and how many iMacs you've exchanged so far

Every week, assuming your participation, I will post an update on the problem. And let me make this point abundantly clear to any Apple corporate folk (because I know you're reading): If your company is still selling multi-thousand dollar computers with yellow screens in 52 weeks, I will be pointing it out in 52 weeks.

This problem will not go away, not until it's fixed. And I implore other sites, technology-based or not, to help me publicize the issue. No, this isn't the first time Apple has sold the public broken products, but maybe, just maybe, it could be the last.

Now having said all that, if Apple can come forward and openly admit the mistake while providing an adequate solution to their customers, I'll laud them as an example as to how companies can take an unforeseen manufacturing issue and make things right.

As for the fate of my iMac, I'm between returning it out of sheer disgust and attempting the repair for sake of our little narrative (plus, you know, I really would like one that works in spite of all this trouble). We'll see.

We should mention, the clip comes from an unconfirmed source, but everything about the system is reminiscent to Natal to us—we should say, Natal running a title in early beta. The control scheme seems simultaneously intuitive and awkward in what we're assuming is a proof-of-concept, the user repositioning their view by moving the screen with their hand.

Still, while the verdict may be out on how well Natal will handle first person shooters, it's pretty darn cool to see a player control a complex game without a controller between them and the screen. And if you were playing an FPS involving the manipulation of a variety of objects beyond mere guns (imagine grabbing a key, crowbar or, heck, even a flower) what's now just a novelty could become something much more compelling.

"Thai, salad or ramen?" It's lunchtime on a typical Thursday and it strikes us that millions of people all over the world are pondering the same question. This question is our launchpad, making us part of the thousands of people who wanted to build an iPhone app for "that."

I'm a product and marketing guy with some design and coding skills. Roy is a developer with some business savvy. Combined, we make a great team and complement each other's skills well, but we only started working with Objective-C last year, like many others who are trying out iPhone development. We've already built an app or two, so we're familiar with the language and frameworks. However, as with all new projects, you usually have to do a little research to understand how to approach the different challenges...especially in a world defined by 320x480 pixels.

For the longest time, we've played around with the idea of creating an app for fun. After discarding a couple of good ideas (because they were too complicated or a quick search in the App Store showed that someone else already does it well), lunchtime lands us on a simple, fun idea to help people stuck between decisions.

But while most people want to create a great iPhone app, my friend and I go one step further, making a pact to finish the project within a weekend—or realistically, our app would never get completed.

On a piece of paper, we scribble out two-three wireframes and developed an outline for some basic screens. We decide on an app that offers up to three multiple choices. You can write your own answers—for example, Thai, salad or ramen—and you simply pick a randomized choice to see the answer to your decision. We decide to use playing cards as the theme. Immediately, we circle the "must have" features (first priority), then the "like to have" features (last priority), and finally the features that needed more investigating. We leave lunch on Thursday with a little homework and a plan to get together on Saturday.

My homework includes determining the look, feel and interaction on each screen. Roy needs to research some of the Xcode features we haven't had a chance to play with yet in our "real" jobs, mainly animations and randomization.

On Saturday morning, we meet at a local coffee shop that had free Wi-Fi, claim a large table so we can sit side-by-side and grab the first of many large cups of coffee. Then we create a shared Dropbox folder for this project—a Basic account is free and comes with 2GB of storage. The Dropbox is important because it allows us to multitask on the same project with any/all changes synchronizing in real time. For larger projects, you may want to consider GitHub.

We pull up a more detailed outline of what we want to accomplish for our app as well as basic wireframes. Given that we only have a weekend to complete this app, we decide to focus only on the "must have" features. A developer can always issue feature updates at a later date to include the "nice to have" features.

Going screen-by-screen, we detail the elements on the page, style treatments, layout, timing, etc. We also discuss what Roy learned about animating the card's flip motion, since this was one of the core functionality of the app. We briefly review the Quartz 2D and Core Animation libraries, since we had not previously done any work with those. We even discuss using a UIWebView to render the animation within WebKit's CSS. Ultimately, we find a simple solution using standard UIViews and UIButtons. The UIView class has some animation class methods, and one of the built in transitions is a flip effect. As for the randomization, we knew most languages provide a random function, and Objective-C is no exception. For purposes of this app, all we wanted was a simple method to randomize an array. Roy found a couple of examples of this, but one that stood out was over at Dr. Touch's website. He describes an approach with which to implement a class extension method so you can easily shuffle any array.

We dive into our respective MacBook Pros with a Borg-like focus on our individual areas of expertise. I open up Photoshop and began building screens. The first screen is the default image. This is the very first screen people see when the app starts and begins loading. Apps can be built in either portrait or landscape view. If you choose to build your app in landscape view like ours, you still need to create a default image that displays in portrait view. Simply create your landscape view and rotate clockwise or counter-clockwise (depending on whether you want left or right landscape view). Now the default image loads in portrait view but since your images is rotated, the user will twist the iPhone to landscape view.

I then spend the next couple of hours creating comps, background images, buttons, card (front and back) and info page. I also spend some time focusing on the app icon. This is obviously the "face" of your app—a badge of honor—so you'll want to put careful thought into the icon imagery. Remember, you'll need the icon in both the 57x57 and 512x512 sizes. Once completed, I upload it to Dropbox so that Roy could start using the creative elements.

By the time I glance back to Roy's laptop, he's created a new Xcode project and is already playing around with code to animate green boxes that flip on a click. While he's working on the prototype in the iPhone Simulator, I grab the info.plist file and edit some of the settings - remove status bar, app display name, remove gloss from icon, etc. We then decide it's time for us to add some real images to our prototype. We put in the background image, the front and back of the cards and the navigation buttons. The positioning is off (by a lot) but the cards look good and it's flipping smoothly. We do some bad math, but eventually get the exact spacing and positioning that we want for each card. We play around with the timing of the flip, set the on/off states for the navigation button and now it's feeling pretty good.

Seeing the pieces come together in the app shows me that there are a couple of images that needs fine tuning. I make changes as Roy begins working on the customizing screen and info screen. The customize screen is the place that allows people to type in whatever they want to show on the face of the card. We limit it to 25 characters... anything more than that and it writes over/outside of the card. We talk through this screen a bit more in detail. The interaction in each field, how the keyboard acts, and how we save before going back to the cards. We spend a bit of time in Interface Builder wiring up exactly how we want this page to look and act. The info page is completely optional, but we like to have it because it includes additional ways to reach us.

Wow, seven hours and fours large coffees later, we have a lot done, but there's still lots more to go. What we have now is an app that fires up; displays a default loading screen; gets people to a screen that shows three cards (back of the card showing); they can select any/all of the cards and the cards flips to show the front of the card; they can click on a button labeled "Try Again" to reset the cards; they can click on a button labeled "Customize" that opens a new screen; the "Customize" screen allows you to enter text into 3 separate fields with a max of 25 characters in each field; and you can get to the Info screen. We spend the last hour of the day together cleaning up code and discussing what we have left to accomplish tomorrow.

On Sunday, we meet at another coffee shop with free Wi-Fi. Coffee first. We feel like we're about 80 percent done before we start working again. The major work left for the day ahead is saving the custom text, displaying the custom text on the face of the card, and randomizing the text. We had additional functionality ideas, but we kept ourselves honest, and kept the scope creep to a minimum. One example of this was the method for storing/saving the custom text on each of the three cards. Roy could have created a sqlite database or used Core Data, but the easiest approach was to just use the built in standardUserDefaults object found in the NSUserDefaults class. Using this method stores the values to the app's settings just fine for our needs and saves us a lot of time.

While Roy is working on those items, it's a perfect opportunity for me to prepare some of the things we'll need later that day. When you submit an app to the App Store, it's not a simple upload of a file. Apple requires the following information for every app submission: Application Name, Application Description, Device Requirements, Primary and Secondary Category, Subcategories, Copyright, App Rating, Keywords, SKU Number, Application URL, Screen shots, Marketing Description, Support URL, Support Email Address, End User License Agreement, and Pricing / Availability.

So, I prep all the app submission information while Roy is busy coding away, first searching the App Store for similar apps and their names. We like "Stuck?" and luckily no one else is using it, so we go with that name. I create the app description, add some keywords, set the price and determine where we want to sell this app (just in the USA, certain countries or worldwide). Then I register a domain name (stuckapp.com) to be used for the application URL/support URL and linked it to a newly created Tumblr account. I also created the required support email address. The other items you'll want to prepare in advance are: screenshots (up to five), a large icon (512x512) and, if this is your first time submitting an app, any certificates/provisioning profiles.

Things tend to take longer than you expect, and even though we're basically finished with the app by early Sunday afternoon, we still spend a couple of more hours tweaking it and preparing everything for the App Store submission—cleaning code and fine tuning as we go along. We spend the majority of the day on one computer pushing pixels, formatting, and ensuring the timing and user interaction was exactly as we both wanted. After almost five hours of work on Sunday, we have the app that we both envisioned. We begin testing in the iPhone simulator and then on devices (both iPhone and iPod touch) for stability and functionality. Again, being a simple app, it was easy and quick to test.

After proving its stability, we decide to publish Stuck? to the App Store. My first attempt at publishing another app by myself took two days—attempt, fail, Google, attempt, fail, Google more, etc.—until it finally worked. But the second time around was much easier and faster. We copy/paste all the text prepared earlier and then added the screenshots and images. All in all, we have our app uploaded in about 15 minutes. At this point, we're excited, hungry and tired, but also quite proud that we completed a solid app over a weekend in a coffee shop.

We had our fingers crossed that the App Store would approve our app. And, as amazed as we were that we could finish an app over the weekend, the real surprise came after we submitted to the App Store. We submitted the app on Sunday evening. It changed status from Waiting for Review‚ to In Review, on Monday. On Tuesday, we received an email informing us that our app was Ready for Sale. Approved in two days! That has to be a record‚ especially before the holidays.

Especially after talking about building an app together for so long, like so many people reading this article, I must say, the fulfillment is immense. We finally did it.

TIPS FOR COMPLETING AN APP OVER A WEEKEND

1. You can't do it yourself. You can, but you wouldn't want to. Ideally, you want to partner with someone with a different, complementary set of skills. Partner with someone who knows and respects your area of expertise, but is even more confident and knowledgeable about their own skills. Good communication is implied in an effort such as this so you'll go through periods of rapid fire questions bouncing ideas off each other and then periods of silence as you work on separate tasks. There's a lot to get done and multitasking will be key.

2. Multitask. As suggested above, working with someone who complements your own skills allows you to multitask. What do I mean? For example, in the beginning, once you scratch out a wireframe of an idea, one person can begin coding - putting placeholder buttons and blocks into place. At the same time, the other person can create comps and then cut out each element to use when they get to the right stage. Also, at the tail end of the project, one person can wrap up the project and clean the code while the other prepares all the images and marketing copy for the App Store submission process.

3. Do at least one thing well. Unlike most desktop applications or web project, you have to remember that most good mobile apps fulfill a need that can come anywhere, any time. Your app idea doesn't have to be complicated, but good apps seem to do one or more of these things well:
- Solves a problem; - Is entertaining; - Serves a specific niche; - Engages the user; and/or - Takes advantage of the unique features of the iPhone.

4. Set goals and milestones. Whether your goal is speed to market, just to gain experience, or to build the best damn app that does (blank), clearly state your goals. Initially, it will help you focus on the areas that are important/critical for success. It will also help you later down the road as you face hard decisions about "must-have" features and "like-to-have" features. Remember, you can always issue feature updates so focus on the "must-have" items and do whatever is necessary to meet that goal.

5. Get a Dropbox account. For small- to medium-sized projects, you cannot beat Dropbox. It allows you to store, share and synchronize files with others. Stop sharing files back and forth on your USB memory stick. Get a Dropbox account and share files in real time. We abused the hell out of our free, shared Dropbox folder and it worked flawlessly. For larger projects, you might want to give GitHub a try.

6. Test. Test. Test. When you see the finish line, it's easy to gloss over the important step of testing your app. Test in your iPhone simulator, but also try to get your hands on an iPod touch and of course on an iPhone as well. Depending on the complexity of your app, you might want to create a test plan to make sure all the use cases and functional tasks are covered. The last thing you want is to have an app in the App Store that crashes or doesn't work as expected. You may never recover from all the ego-shattering feedback.

7. Understand the App Store submission process. Apple provides a PDF document detailing to submission process. But that document is only available for registered developers. If you've already registered, read that document thoroughly before you begin the upload process. It will give you a good idea of what's involved, but also what you'll need to prepare in advance. Apple also provides some good tips for app store submission and approval .

Thanks to David Quinlan for sharing his story and advice with us. If his narrative has compelled you to try out Stuck?, it's $1 at the App Store. And, of course, share war stories of your own long weekends writing apps in the comments. [Stuck]