Listing Aliases Inside an Android Keystore File With Keytool

If you lose or forget your Android keystore file alias that is used to build APK files for distribution (like I did when trying to package Autoridge Lite for the Android Market), here is a quick and easy way to see them:

  1. Open a Terminal Window, Run This Command:

    keytool -list -keystore /location/of/your/com.example.keystore

    Make sure "keytool" is either in your PATH, or "cd" into the "tools" directory where your Android SDK files are.

  2. Enter your keystore password when prompted (you didn’t forget that too, did you? Did you?)
  3. See results! You should see something like the picture below if you did everything right. The alias is circled in yellow. If you have multiple aliases in your keystore, they will all be listed, one per line.

Continue reading

Zero to App in Two Weeks with Titanium

Like any web developer who has been sitting on the sidelines watching this mobile explosion happen in front of my eyes, I was eager to find a way to jump in. Up until about a month ago, I was still evaluating various different mobile development platforms – Titanium, PhoneGap, and Rhomobile, trying to decide which one I wanted to use to make my first mobile app. My only selection criteria was that the platform would have to be able to produce both iPhone and Android apps with the same code, because I wanted to be able to develop and release both an Android and iPhone apps without having to learn two completely different programming languages and development environments, and without having to do everything twice.
Continue reading

Practical Uses for PHP 5.3 Closures

Closures are a new language-level feature that has been added to php 5.3, along with namespaces, late static binding, and a slew of other new features, patches, and updates. If you’re like me, you might be wondering what the practical uses for these new features are before you can rightly justify diving in and using them in new or existing projects. I experimented a lot with closures and possible uses over the past few weeks, and came up with some compelling reasons to start using them.

Continue reading

MongoDB Gotchas

Most developers are coming from a background with relational database-specific experience, and then trying out some new NoSQL databases like MongoDB. Here are some “gotchas” I ran into while using MongoDB with my MySQL hat still on.

Continue reading

NoSQL First Impressions: Object Databases Missed the Boat

I’ve spent the past few weeks here at work researching and playing with NoSQL databases (and especially MongoDB) for a new feature we’re developing that doesn’t easily fit into a relational model. And so far, I really like what I see. The profoundness of the shift away from the relational model and the implications that has just blow my mind. You no longer have to fragment your data to persist it . You just store it. That’s it. No more hours toiling over the design your table schema and how to break apart the data you put together just to fit it into a relational model. You can now store your data exactly how you use it in your application, with no other special needs or impedance mismatches. Going back to an RDBMS system now just seems illogical – it’s like breaking apart a camera tripod just to fit it in the same standard size case you’ve been using for years instead of just collapsing it and finding a different case that fits it better. All that effort you go though tearing down your tripod and putting it back together every time you use it is wasted and unnecessary. It’s a symptom of the larger problem that your case doesn’t fit your tripod. more

Once you fully get the NoSQL viewpoint and the implications it has on the future of data storage, you have one of those “why didn’t anyone think of this sooner?” moments. And yes, I know key/value stores like memcached existed long before this whole new “NoSQL” movement, but it’s not quite the same thing.

Object Databases

Object databases are an interesting case. They are in the “NoSQL” category and solve the same problem other NoSQL databases do – creating a storage mechanism that fits your data instead of making your data fit a predefined rigid storage mechanism. So why didn’t they catch on? What gives? It’s anyone’s guess why object databases didn’t catch on and achieve widespread adoption, but one thing is for sure – object databases really missed the boat while other NoSQL database technologies are running rings around them.

The primary problem is that most object databases are designed for a specific language, like Java or .NET. Some have more language support than others, but the problem is still the same – by integrating in directly with a language’s object model they depend on specific language implementations, which severely limits adoption. They solve the impedance mismatch problem that RDBMSes present, but fail to provide language-agnostic data persistence and access , effectively tying their use to specific technology stacks and platforms.

The Best of Both Worlds

NoSQL databases are gaining traction like no other database technology has in over 30 years. The reason is that good NoSQL databases solve both key data storage problems: impedance mismatches AND language-agnosticism. By storing the data in an intermediary format like JSON (or BSON) and allowing custom file content types, the focus is on the actual data itself instead of specific technologies or data models. The technology stack becomes irrelevant, and the walls to gaining user adoption crumble.

The bottom line is that NoSQL databases are not just the latest fad. They represent a fundamental paradigm shift in data storage and are an entirely new way of thinking about how to store and access your data in a way that makes sense for your actual usage. NoSQL databases are absolutely something you should be paying attention to and following closely – they are a strong contender to the RDBMS model and will likely become the de-facto data storage choice for most new web applications within a decade and a solid alternate choice.

MySQL Series: How to Detect UTF-8 and Multi-byte Characters

Multi-byte characters can cause quite a few headaches for the unsuspecting webmaster. Sometimes all you need to do to figure out how to fix the problem is detect which database records have UTF-8 data in them and which ones do not. If you’ve been scanning records manually, stop now. Here’s a quick query to cure your ales:

Return all the rows with multi-byte characters in table posts on field title:

SELECT * FROM posts WHERE LENGTH(title) != CHAR_LENGTH(title)

This does pretty much what it looks like: returns all the rows in the posts table where the title’s character length does not match the title’s length. This works because the LENGTH function returns the number of bytes in the string, while the CHAR_LENGTH function returns the number of characters in the string. If the string contains multi-byte characters (individual characters that are made up of more than one byte) like international UTF-8 characters, the two functions will return different numbers and will not be equal, thus including that row in your results.

Get Only Public Class Properties for the Current Class in PHP

PHP provides two built-in functions to retrieve properties of a given class – get_object_vars and get_class_vars. Both these functions behave the same exact way, one taking an object as a variable and the other taking a string class name. The tricky thing about the two functions is that they behave differently depending on the call scope, returning all of the class variables available within the called scope. So if you call either function within the current class you need properties from, all properties are returned – public, protected, and private – because the current scope has access to them all. This makes seemingly simple things like returning all the public properties within the current class a bit of a pain if you want to keep the code inside the class itself.

Continue reading

MySQL Series: Return NULL Values First With Descending Order

Sometimes there are unique situations where you need to order query results by a particular field in descending order, but also need NULL values first. The default (and logical) behavior of MySQL in this case is to return NULL values last, because in descending order they have the lowest value (none). But what if you really need to reverse this and force NULL values to the top of the result set?

Continue reading