February 8th, 2010

Kindle developers: Don't ask, don't tell

Posted by Ed Burnette @ 5:57 am

Categories: General, Programming

Tags: Developer, Source Code, Agreement, Labor Relations, Human Resources, Ed Burnette

Hypothetically speaking, if I had received an invite to join the Kindle Development Kit (KDK) for active content limited Beta program, which I didn’t, and had read over the Terms and Conditions for the KDK, which don’t officially exist, I wouldn’t have seen this section:

You will not, without our prior written consent, use our trademarks, trade names or logos in any manner, or issue or contribute to any press release or any other public statement relating to the Program, our relationship with you or the terms or existence of this Agreement.

If such a policy existed, and I’m not saying it does or doesn’t, it might prevent anyone from disclosing that they were even working on any Kindle apps. It’s a good thing I’m not doing that. And I certainly wouldn’t be able to share any source code examples or documentation from the KDK with you because the non-existent policy might say:

We will from time to time provide you access to certain software, documentation and related materials (the “Materials”) in our sole discretion. … You will not use or authorize a third party to use any software in a manner that would in any way cause the Materials to be licensed free of charge, distributed in source code form or modifiable other than as expressly permitted in this Agreement.

It’s really too bad the beta program doesn’t exist because if it did I could tell you about the neat <redacted> feature, the fact that the whole thing is based on <redacted>, or the <redacted> limit of <redacted> KB/month. Wow, I can’t believe nobody has reported on that yet.

So… what could we talk about instead? How bout ‘dem Saints?

January 28th, 2010

Computer-driven trading puts stock exchanges at risk

Posted by Ed Burnette @ 6:58 am

Categories: General, Programming

Tags: Stock, Computer, Productivity, Ed Burnette

Here’s a scary thought for you. Every day, hundreds of billions of dollars of financial transactions are driven completely autonomously by computer algorithms. The fate of corporations and nations rests on bits of computer code sent out by their makers to do battle in a high-stakes trading war. And when something goes wrong, it can go spectacularly wrong.

When you think of stock exchanges you probably have a quaint notion of a paper-strewn room full of stressed-out traders yelling to be heard over each other while watching big screen monitors that cover every square inch of the walls. Or maybe you have a more modern picture of an army of white collar workers barricaded in their caves of steel intently staring at computer displays, waiting to pounce on the right news or slightest movement by executing a quick buy or sell order.

In reality, today’s markets are largely driven not by bellicose bombasts or educated elites but by algorithms written by programmers like you and me. Programs that are set free to wreak profit (or havoc) in the innards of the world’s electronic cyber-market. According to the Financial Times, program trading accounts for about 30% of the total daily activity on the New York Stock Exchange, and a whopping 60-70% of the activity on other markets such as the Nasdaq. In 2008, the total world derivatives market was estimated at nearly $800 *trillion* dollars.

Unsatisfied by the decision speeds of mere humans, huge banks have turned over the keys to the vault to programs to do the trading of stocks and derivatives for them. The idea has a certain appeal: Put in a few billion dollars, push a button, and walk away while the computer does all the work. When you come back, if all goes well, you’ve made a nice profit. “Leave the driving to us,” as the slogan goes. Even a monkey could do it. Right?

Well, if you’re not a developer and you’re reading this, please take heed. Computers make mistakes, because they just do what their programs tell them to do, and all programs have mistakes lurking in them. “Bugs,” we call them. Much of the craft of computer programming is concerned with reducing the number of bugs. When a program controls something really important, like say an X-Ray machine, a fighter jet, a space craft, or a nuclear power plant, extreme efforts are put into eliminating as many bugs as humanly possible. But as a number of high profile cases have proven, it’s impossible to detect them all.

Take the case of the NYSE Euronext exchange operator. Recently it fined a trading firm for “failing to control” its trading algorithm. One day, out of the blue, the program decided to send “hundreds of thousands” of messages for faulty orders, clogging up the exchange for everyone for hours. All it takes is a bad “if” statement or a misplaced semicolon, or maybe an array that grows larger than expected or a race condition in multi-threaded code. Let’s not even mention what a malicious hacker with an agenda can do.

So what’s the fix? Acknowledge that bugs happen, and put in checks and balances to catch and contain them. Don’t assume computers are infallible. They’re just as fallible as the humans that build and program them. More, because humans have the advantage of common sense. Let’s use it.

Photo credit: Walt Dabney

January 12th, 2010

Android 2.1 (Eclair MR1) SDK is out

Posted by Ed Burnette @ 7:11 am

Categories: Android, Google, Programming

Tags: Google Inc., Voice Recognition, Multi-touch, API, SDK, Android 2.1, Telephony, Networking, Ed Burnette

One week after releasing the Android Nexus One phone to the public, Google has released the software development kit (SDK) that allows third-party developers to write applications for the phone. Android 2.1 has several new features including:

• Live Wallpapers
• Support for HTML5 video, geolocation, and web storage in WebViews
• New APIs for determining cellular signal strength
• New methods for Android views such as automatic view flippers and opaque views
• Support for a voice recognition audio source and camera-facing microphone
• New features that an app can optionally require before installing, including a multi-touch screen

Version 2.1 is also referred to as Eclair Maintenance Release 1 (MR1), or API level 7 to programmers. In all, 2.1 has 118 API changes, which is approximately a 0.48% difference compared to the previous version.

Availability

Android 2.1 is currently shipping on the HTC Nexus One. The Motorola Droid (Sholes) sold by Verizon is currently at 2.0.1 but users should expect an over the air update “soon” (which could mean anything from 2 weeks to 2 months). As of this writing, all other Android devices (about 80% of the market, according to Google) are running version 1.5 or 1.6:

Source: Google market data collected during the two weeks ending on 1/4/2010

Eventually 2.0.1 will go away, replaced by 2.1 just as 2.0 was replaced by 2.0.1. If current trends continue, we predict that 2.0.1/2.1 will achieve a 25% market share by February, and 50% by the end of the year.

Note that all programs written using the 1.5/1.6 APIs should work on newer devices, but you should test your apps on all targeted versions and screen sizes just to make sure. Programs written to require the 2.0.1/2.1 APIs will not work on older devices.

January 11th, 2010

Are SSDs too fast?

Posted by Ed Burnette @ 7:19 am

Categories: Dell, General, Programming

Tags: Mozilla Firefox, Disk, Disk Drive, Memory, Solid State Disk, Computer, Reboots, Productivity, Ed Burnette

When buying a new computer, the conventional advice is to buy the fastest one you could afford. That’s what I did when I recently replaced an aging laptop with a desktop screamer sporting an Intel Solid State Drive (SSD). But now I wonder, for those of us developing software for others to use, are we doing our users a disservice by always getting the latest and greatest?

My IBM ThinkPad T42 served me well for many years but it was beginning to show its age. For one thing, the 40GB disk drive was always running out of space. I used a great program from JAM software called TreeSize Pro to track down where the space was going, but there was a point of diminishing returns.

I upgraded the memory as much as I could, but the Pentium M 1.7GHz CPU running Windows XP had reached its limit. Rebooting took over a minute, and starting Firefox or Eclipse could take 30 seconds or more. Running the Android development emulator was especially painful: several minutes to start one instance, and don’t even think about starting two or more.

After months of reading excellent technical reviews of the Intel Core i7 and Intel SSD’s at anandtech.com and other sites I decided to take the plunge…

Read the rest of this entry »

December 7th, 2009

Larrabee, we hardly knew ye

Posted by Ed Burnette @ 10:42 am

Categories: Apple, General, Programming

Tags: Developer, Intel Corp., Chip, GPU, Larrabee, Ct, GCD, Linux, Semiconductors, Network Technology

Intel has announced that Larrabee, the multi-core AMD and NVidia GPU killer, has been canceled. While Larrabee research lives on and we might see it re-emerge in some form in the future, it won’t be any time soon.

Larrabee was appealing to developers because it used a standard x86 instruction set plus some additional vector processing units and a conventional memory architecture. In theory, this should be easier to program than CUDA or Cell because of its familiarity to programmers, generous memory sizes, and fast pathways to get data in and out of the chip.

Another project at Intel, called the Single chip Cloud Computer (SCC), is similar to Larrabee in that it uses an array of simple x86 processors. However SCC uses a mesh router network instead of Larrabee’s ring, and appears to be targeted towards running cluster applications (currently coded with MPI and run on commodity Linux servers) instead of SIMD applications (currently coded with threads or chip-specific APIs like CUDA).

Intel would like developers to use architecture-neutral languages like Ct in order to exploit the vectorization capabilities in current Intel chips and get ready for many-core hardware in the future. Ct is not yet in public beta, though there was a similar product available from RapidMind before Intel bought them and folded them into Ct. Ct takes an algorithm written in C++ templates, translates it to an intermediate format, and compiles that format at run time to best use whatever hardware you have. It works best, of course, on Intel hardware.

Another option for developers is OpenCL, a GPGPU extension of OpenGL. Compatible drivers are only just beginning to appear for ATI and NVidia hardware. It will run code on the GPU, the CPU, or a mixture of CPU and GPU, depending on your hardware.

Of all the options currently available for multi-core programming, the one that appeals to me the most right now is Grand Central Dispatch. It uses nice, clean extensions to the C and Objective-C languages plus some operating system support for system-wide lightweight thread scheduling. GCD has been ported to MacOS X and FreeBSD. Until it is available on Linux and Windows, however, it doesn’t have any hope of becoming mainstream.

November 5th, 2009

New Epic 3D game engine toolset: Fabulous, fun, and free!

Posted by Ed Burnette @ 12:05 pm

Categories: Commercial, Community, Games, General, Licenses, Programming, Scripting

Tags: 3D, EPIC, Epic Games, Unreal Engine, Games, Personal Technology, Ed Burnette

This is big: Epic Games just announced the release of the Unreal Development Kit (UDK), a free edition of the Unreal Engine 3. It’s available to anyone interested in using 3D game engine technology, including game developers, students, hobbyists, researchers, creators of 3D visualizations.

The Unreal Engine is the technology behind popular PC and console games such as Gears of War, Unreal Tournament, Bioshock, Medal of Honor, Army of Two, and Batman: Archam Asylum. It’s one of the best game engines available today. See the UDK features page for more details on all of its capabilities.

Previously, if you wanted to use the Unreal Engine in your programs you had to enter into a very expensive agreement with Epic for access to the technology. A few years ago, Epic reportedly asked for up-front payments of as much as $8 million before your game was even developed! Now anyone can download the PC version of the UDK and immediately try it out without paying a cent or signing anything. As a former professional game developer, this is just amazing to me.

The Unreal community was going nuts this morning after the announcement. Some were shocked that Epic chose to release the entire engine and not just a crippled subset. As one poster put it,

“Man, one thing I hope you guys realize is that this is almost EXACTLY the engine build that we’re using here at Epic! You get every single feature that we’ve been using here that aren’t even in any games yet! We only got some of these features last week!”

Use of the new UDK is free for noncommercial purposes, but it can be licensed cheaply for commercial uses. For example you can use it to write a commercial PC video game and pay nothing up front and no royalties until your sales go over $5,000. See the licensing page for all the details. Currently, the free kit is only offered to PC users but Epic says console support is “under consideration”.

“Unreal Engine 3 has been used to create games in a wide range of genres, as well as military simulations, 3D architectural walkthroughs, animated movies and more,” said Epic VP Mark Rein. “Users are only limited by their imaginations. Go ahead, make something Unreal!”

Related articles:

• Epic Offers Free Unreal Engine 3 Dev Kit, New Licensing Deals
• North Carolina’s Research Triangle–“the hub of East Coast video games?”
• Never mind the recession, the Triangle computer gaming industry is booming

October 29th, 2009

Android 2.0 (Eclair) FAQ

Posted by Ed Burnette @ 8:54 pm

Categories: Android, General, Google, Programming

Tags: Google Inc., High Tech Computer Corp., Phone, FAQ, Emulator, Android 2.0 Software Development Kit, Q., Q. Does Google, Telecom & Utilities, Ed Burnette

This is the last of a series of articles on Android 2.0 (”Eclair”). In part 1, we examined the user-oriented features of the new release, and in part 2 we discussed several features intended for developers. For this final part we’ll switch gears and answer some frequently asked questions about Eclair from both users and developers. Just for fun I’ve tossed in a few questions about the Motorola DROID as well.

By the way, if you have any questions that I didn’t cover, just ask them in the talkback area.

Q. When can I get Android 2.0?

The Android 2.0 Software Development Kit is available now. This includes an emulator that lets you run a virtual Android device on your desktop computer.

The first phone with Android 2.0 installed is the Motorola DROID, which will be carried by Verizon in the US starting November 6th. The second one will probably be Sony Ericsson’s Xperia X3/Infinity/Rachael . A release date for that model hasn’t been announced but it’s widely expected to be out before the end of the year as well.

Q. Will the Acer A1 Liquid phone with Snapdragon have 2.0?

Liquid is set to be released with Android 1.6.

Q. Can I upgrade my ___ (fill in the blank) phone to 2.0?

The only one we know for sure that will be upgraded is the HTC Hero.

It has been rumored that the first Android phone, the HTC G1/Dream, doesn’t have enough memory to run 2.0. However, I don’t think that will necessarily be the case. If you remember, they said the same thing about version 1.6. Like 1.6, 2.0 is a little too big to fit into the G1’s memory. But with a few optimizations, 1.6 was slimmed down enough to fit, so the current speculation is that 2.0 can be made to fit also. …

Continue reading: Android 2.0 FAQ >

October 28th, 2009

What's new in Android 2.0? Part 2: Developer features

Posted by Ed Burnette @ 12:17 am

Categories: Android, General, Google, Programming, Web Browsers

Tags: Device, API, SDK, Android 2.0, Android 1.6, KeyEvent, Ed Burnette

After months of speculation, Android 2.0 (”Eclair”) was officially released this week by Google. To be more precise, the Software Development Kit (SDK) for Android 2.0 was released, so that developers can get a head start on 2.0 development before the new devices with 2.0 hit the market. It’s not much of a head start, though, because the new devices may will be on sale as early as next week, or by the end of November at the latest.

[ See Motorola DROID on Verizon: Is this the iPhone killer you're looking for? for the first Android 2.0 phone. ]

This is the second of a series of 3 articles covering what’s new in this new release. Part 1 covered user features and availability, this part will cover developer features, and part 3 will try to answer any other questions you might have about the new platform. You should read part 1 first, if you haven’t already.

Should I stay or should I go now?

In the announcement of version 2.0 on the Android Developer’s blog, Xavier Ducrohet wrote:

Over the next few months, we expect to see more and more Android devices being released. These devices will be running Android 1.5, 1.6, or 2.0. We are also planning a minor version update of Android 2.0 towards the end of the year, and that will be the last update for 2009.

That’s right, folks - by the end of this year there will be 4 different versions of Android running in the field. It’s going to be a challenge for developers to keep on top of this. One thing seems clear - all Android devices will not automatically be upgraded to the latest version:

• Android 1.5 provides the base functionality common to all versions of Android.
• Android 1.6 adds support for screen sizes smaller and larger than HVGA 480×320.
• Android 2.0 adds support for multi-touch and virtual keys, among other things.
• Android 2.1 will probably be a minor bug-fix version.

With rare exceptions, 1.5/1.6 apps will run fine on 2.0 phones. Most apps will not need the new features that 2.0 brings, so they can continue to use the 1.5 SDK and get the greatest possible reach. Other apps can test to see if they’re running on 2.0 and only use new features if they are available. A few apps, however, will want to require 2.0 and rely on its features even if it means they can only be run on a few new devices (for now, anyhow).

Continue reading: What’s new in Android 2.0 for developers >

October 16th, 2009

First pics of Motorola Droid with Android 2.0 build (maybe)

Posted by Ed Burnette @ 1:00 pm

Categories: Android, Commercial, Community, Eclipse, General, Google, Programming

Tags: Multi-touch, Motorola Inc., BGR, Ed Burnette

The Boy Genius report has just posted a series of screenshots showing Android 2.0 running on what appears to be the upcoming Motorola Droid phone (also known as Sholes). The source is credible and the pictures look real, though it’s unclear how close it all is to being finished. Pricing and availability was not announced.

Small visual changes can be seen in several of the shots when compared to the stock Android 1.6 image. For example, some of the home screen icons are different, and the browser has a redesigned address line with space for the site’s “favicon”. The key lock screen looks quite different too. But it’s hard to tell whether these are due to Verizon customizations or changes in Android 2.0. The phone dialer looks different, but it also looks different on the Acer Liquid A1 phone which appears to be running 1.6. The only thing that screams “2.0″ is the Firmware version shown on one of the screen shots. You can see another view of it here. If it had said “1.6″ there I would believe it, chalking up the minor changes in the screen shots to vendor mods.

Read the rest of this entry »

October 5th, 2009

What's new in Android 1.6 (Donut)? Part 2: Developer features

Posted by Ed Burnette @ 6:50 am

Categories: Android, General, Google, Programming

Tags: OpenGL, Developer, Phone, Permission, API, Android 1.6, Telecom & Utilities, Advertising & Promotion, Marketing, Ed Burnette

Over the next several weeks, Android 1.6 will be rolling out to customers via an over-the-air update. In addition to a number of user-facing features such as a new Android Market and a faster camera application, the Donut branch has a few goodies for developers as well. This article explores how to get 1.6 right now, and the developer-facing features inside.

[ See also: What's new in Android 1.6? Part 1: User features ]

Continue reading: Getting 1.6 early >