At work, we have been receiving reports of people, particularly on Android 2, not being able to install from the Google Play Store citing an error message “Package file is invalid“. At the same time, I was trying to test one of the features I was developing on a couple of Android 2 test devices we have in the office, but I was repeatedly getting an INSTALL_FAILED_DEXOPT error from adb. It seemed that both of these issues could be related.
Continue Reading
Software Development
Checking for a Null value in SQL
Yesterday I fell into a very simple but dangerous SQL trap. Can you identify it?
SELECT first_column, another_column FROM my_table WHERE first_column = 1 AND (another_column >= 100 OR another_column = null)
Found it? It’s the comparison to null. My intention was to get rows where another_column was null, however the query did not do so. It didn’t give me any results where another_column was null, but didn’t give me any error either. Why?
Null in SQL is not a real value. Null means “lack of a value” or “unknown”. Anything compared to null leads to an “unknown” result. Therefore, in SQL there are actually three values conditions can evaluate to: true, false, and unknown/null. This is called three-valued logic. SQL WHERE clauses only return rows that evaluate to true, not rows that evaluate to false or “unknown”.
The proper way of checking for null is by using the IS NULL or IS NOT NULL predicates. The correct SQL query would have been as follows:
SELECT first_column, another_column FROM my_table WHERE first_column = 1 AND (another_column >= 100 OR another_column IS null)
So if you’re used to languages where you check for null with equal signs, remember that in SQL, you must use the special IS NULL or IS NOT NULL predicates instead of the equals sign or other comparison operators. Don’t get tripped up like I did.
If you want to read more about, Wikipedia has a detailed article on null in SQL.
iOS Screen Resolutions
iOS screen resolutions from an app developer’s point of view.
2007: In the beginning
Back in 2007 when the first iPhone and iPod Touch were launched, iOS developers only had to worry about one resolution: 480×320. Its aspect ratio is 3:2.
Life was great.
2010: The retina displays
Fast forward three years and three generations later. In 2010, the iPhone 4 and iPod Touch 4th generation were launched with the first Retina Displays, which doubled the resolution of the screens. The new resolution thus was 960×640. This was great for developers as the new resolution had the same aspect ratio of 3:2. This meant that layouts and graphics were pretty much backwards compatible. The only thing would be that using non-retina images on a retina display would just look a little worse. All app developers needed to do was double the size of the images used in their app and call it a day.
The iPad
Also in the same year (2010), the iPad launched with a resolution of 1024×768 (aspect ratio 4:3). Obviously a tablet will have a different aspect ratio than a phone. So now, essentially developers needed to maintain two layouts for the app, one for iPhone, one for iPad.
Life was still quite good.
2012: A longer iPhone
Moving forward to 2012, Apple released the iPhone 5 and the iPod Touch 5th generation. Apple finally decides to jump on the 16:9 train, so these devices have a 1136×640 resolution (it’s close enough to 16:9).
The iPad retina displays
The iPads also get retina displays in 2012. They have a resolution of a whopping 2048×1536 pixels (which can’t even fit on most people’s computer monitors). But as the aspect ratio is kept the same, this is much like the iPhone retina upgrade above. Between 2012 and 2013, the iPad Mini and its retina version are also introduced with the same resolutions as their larger siblings.
Alright so developers have to keep three variations of layouts in mind now: 3:2 for the old iPhones (plus 1x and 2x graphics for original and retina displays respectively), 4:3 for the iPad (also with 1x and 2x) and ~16:9 for the new iPhones and iPods.
Life was manageable.
2014: A bigger iPhone
Jump ahead again two years. We now see the iPhone 6 and iPhone 6 Plus being launched. Their resolutions follow 16×9 and are respectively 1334×750 and 1920×1080. The iPhone 6 Plus also handles 3x image assets.
Now, for app developers, layouts that need to be considered include 3:2 (old iPhones and iPods), 4:3 (iPads), 16:9 (new iPhones and iPods). In addition, three versions of the image assets are required, 1x (original displays), 2x (retina displays), 3x (iPhone 6 Plus).
Tools
Thankfully, Apple has also improved Xcode throughout the years with tools in order to help with this task. Things like Auto Layout help with varying screen sizes and orientations (if you’re willing to throw away support for older devices).
And I guess it still beats the fragmentation in the Android world.
If you need help figuring this out, check out the following links:
Database query optimization is a useful skill
Recently I read an article titled “Quick tip: Improve developer habits by showing time cost of DB queries” by Dan Birken. He claims that one common reason why websites load slowly are because of unoptimized database queries:
Websites can be slow for many reasons, but an overwhelmingly common one is time spent performing database queries. Now database queries are likely a very important part of rendering the webpage – the information to populate a page has to come from somewhere. But sometimes rendering a page is slowed down by either unnecessary queries or improperly optimized queries.
I completely agree with his view. For most web developers, querying information from a database is quite a common action. Therefore, I believe learning how to write efficient and optimized database queries is a good skill to have.
I was fortunate to learn about this topic when I was developing MyBB way back years ago. At the bottom of each MyBB page, administrators are shown debugging info with a summary of loading times and other statistics.
Clicking on the “advanced details” link yields a much more in-depth analysis of the page generation, including an explanation of all the database queries used to create the page.
This is very useful to determine where the bottlenecks occur when generating the page. Some common mistakes include repeating similar queries instead of batching them together, selecting more data than is needed, and doing full table scans rather than indexed queries.
However, not all software and web frameworks has built-in performance debugging pages like what MyBB has. If you’re programming something from scratch, it might take some extra effort to create a useful debugging interface. What other tools can we use then?
Using the EXPLAIN query (works at least for MySQL, PostgreSQL, SQLite) will give you the details about how a specific query will be executed by the database. All you need to do is to tack “EXPLAIN” on at the beginning of your SELECT query, and run it through your favourite database management program. SitePoint has a thorough article on how to understand the output of an EXPLAIN query.
Of course, it’s also beneficial to have a concrete understanding of database indexes and how they work. One of my favourite sites on this topic is Use the Index, Luke! They also have a fun 3-minute quiz to test your knowledge, if you think you already know everything 😉 (I got 4/5 on my first try, how about you? 🙂 )
Do you know of any other resources to help with optimizing database queries? Let me know in the comments.
Heartbleed
The Heartbleed vulnerability has been all over the news this past week. As usual, the media sometimes twists the facts, sometimes intentionally, other times inadvertently. For example, I’ve heard Heartbleed being called a virus, or being framed as something that was deliberately created to be malicious. Also, from reading people’s comments on the online news articles and blog posts, it seems that many people don’t really understand what Heartbleed is or does. From my point of view as a software developer, I would like to provide some information and resources that I believe are true and report the facts (but as I’m not an expert in the field of encryption/security, you may also want to take these with a grain of salt).
Heartbleed explained
What Heartbleed is simply a software bug. Sure, there are bugs in nearly all, if not all, software out there (obviously we developers try not to introduce bugs, but we humans are unfortunately imperfect 🙁 ), but what makes this particular bug newsworthy?
- This particular bug is a vulnerability, which allows a malicious attacker to gain information that should not be accessible.
- The bug is in a library (called OpenSSL) that is used in a number of programs that in turn are run on a large number of computers worldwide.
- The vulnerability has been out in the wild for two years.
- There’s no trace left behind by a malicious attacker exploiting this vulnerability.
I came across this XKCD comic last night. I think it’s a pretty simple way to understand what the Heartbleed vulnerability allows a malicious attacker to do.
The comic illustrates the case where the victim is the “server” and the malicious attacker is the “client.” This is the case that most people are concerned with, as it is likely that servers running the exploitable software are easier to find and will probably have more “interesting” data in the memory. The data could potentially be usernames and passwords, credit card information, or encryption keys, but on the other hand it could also be just bogus data that happened to also be in memory. The data that the attacker could gain really depends on what happens to be in adjacent memory at that time.
However, the vulnerability exists both ways (if the software on the “client” is using a vulnerable version of OpenSSL). You could be owning a device or running a program on your computer that might allow a “server”, which has been maliciously programmed, to read memory off of your device using the same exploit. For example, Android 4.1.1 devices are susceptible to Heartbleed.
Although web servers are the most common targets being mentioned, there are other services that could possibly be affected by Heartbleed including FTP servers and mail servers.
If you are interested in the nitty gritty details behind how the exploit works, CloudFlare has an article on the low-level details (just disregard the fact that they say that private keys aren’t accessible because they were disproved on that point). For higher level information on Heartbleed, the heartbleed.com site has very clear information and a nice FAQ. Troy Hunt also has an informative FAQ about Heartbleed.
What to do about it
For end users
Since there is no trace when an attacker exploits Heartbleed compounded by the fact that Heartbleed has been vulnerable for over two years, it’s not possible to determine exactly what data has been compromised. In addition, if encryption keys were gleaned from Heartbleed, it is possible for even more data to be compromised by decrypting historic logs (if they exist in the hands of the attacker).
So for end users, the precautionary recommendation is to change your passwords after the services that were affected have been patched. Mashable has a running list of the status of popular web services that you can use to determine whether to change your password. In case you use a service that isn’t listed there, you can check it yourself on Filippo Valsorda’s test site. However, keep in mind that not only web services are affected. There are recommendations not to login to services that are still known to be vulnerable because when you login there is a chance that your credentials will be placed in memory, which is susceptible to be read. In addition, ensure that all the software and operating systems you are running are up to date.
For system administrators, developers and service providers
Obviously, ensuring that OpenSSL is up to date or patched is top priority. Troy Hunt provides some additional advice in his blog post.
Heartbleed and the goto fail and GnuTLS bugs
Heartbleed isn’t related to the Apple goto fail or the GnuTLS bug we’ve seen in the past couple months. The goto fail and GnuTLS bugs are susceptible to man-in-the-middle attacks where a malicious intruder can pretend to be the trusted service you’re communicating with and intercept messages between you and the service. Heartbleed on the other hand allows attackers to read parts of the computer’s memory that they should not have access to.
OpenSSL and open source projects
OpenSSL is an open-source project with eleven volunteer developers, maintaining one of if not the most used SSL/TLS libraries, probably on their own time. I think they should be respected for taking on the heavy responsibilities of this project.
Open-source projects allow external developers to read the source code and even submit improvements and contributions. Depending on the project, there are different procedures to getting contributions accepted, usually including a code review process where the core maintainers ensure that the contributions work as intended and meet the standards of the project (kind of like how a newspaper editor goes over the articles of his writers before they get published). Since humans aren’t 100% perfect, bugs and mistakes unfortunately happen, as much as we try not to allow them.
While it is possible to order security audits of software, for open-source projects that usually don’t generate any profit, it is difficult to come up with the money. I remember when we got a security audit for MyBB, it was in the order of thousands of dollars.
Conclusion
There is a lot of information about the Heartbleed vulnerability on the news and media, and from reading the comments on many of the blog posts and news articles I have read, many people don’t really understand what Heartbleed is and its implications. I hope that this article sheds a little bit of light on that, and provides more resources for those who want to dig a little deeper in understanding it.