Archive
iOS 4 – iPod controls discovery
Fortunately it hasn’t completely. When the phone is locked, a double press on the home button brings up the standard iPod control screen I find so useful:
On the other hand, when you’re in a standard app and double tap the home screen you’ll see the bar pop up at the bottom of the screen with the apps you can switch between. I stumbled upon the fact that you can swipe this bar of icons over towards the left and the iPod controls are visible without having to explicitly hop out of your app and into the iPod controls.
While it’s not two taps and a swipe to get to the controls as opposed to just two taps, this is a very small price to pay for the multitasking of iPhone OS 4. Hopefully this is useful to someone who hasn’t discovered this already.
Quick hit: Take Maven offline in NetBeans
I use the Maven plugin to NetBeans and once in awhile the plugin gets hung up on trying to download an updated version of a jar that I’ve installed locally and that it would have no hope of ever finding online. To get around that I’ve always run mvn install -o (or –offline) from the command line; this forces Maven to stop searching for updates to the jars. I found a blog post detailing how to enable that same setting for the Maven plugin.
In short, go to Tools->Options (or Netbeans->Preferences on Mac), then choose Miscellaneous, and then choose Maven. You can enter command line arguments within the Global Execution Options. See the following screenshot:
Of bugs and purple wires
I picked up a copy of Frederick Brooks, Jr.’s seminal work, “The Mythical Man Month: Essays on Software Engineering” a few weeks ago and finished it this past weekend. Despite being written over three decades ago, there is a lot of great content here, and much of it still relevant. One quote that struck me comes towards the tail end of the book, and orthogonal to the more commonly cited content about the futility of adding more developers to a late project.
In System/360 engineering models, one saw occasional strands of purple wire among the routine yellow wires. When a bug was found, two things were done. A quick fix was devised and installed on the system, so testing could proceed. This change was put on in purple wire, so it stuck out like a sore thumb. It was entered in the log. Meanwhile, an official change document was prepared and started into the design automation mill. Eventually this resulted in updated drawings and wire lists, and a new back panel in which the change was implemented in printed circuitry or yellow wire. Now the physical model and the paper were together again, and the purple wire was gone.
Programming needs a purple-wire technique, and it badly needs tight control and deep respect for the paper that ultimately is the product. The vital ingredients of such technique are the logging of all changes in a journal and the distinction, carried conspicuously in source code, between quick patches and thought-through, tested, documented fixes.
System Debugging, p. 149
I wonder, has much changed in the past thirty plus years in software engineering? What is the equivalent of the purple wire? The best I can think of is ensuring that no bug is fixed without a corresponding unit test being put into place to validate the change and to guard against regression. I am very new to the industry, however, and I would love for the more experienced of my readers to share their thoughts on the matter. How do you ensure that the quick fix that inevitably gets put in with a quick // TODO: Remove this hack comment actually gets the attention it deserves? Is it just a matter of every coder being ultra-vigilant? Does your company have certain standards and practices relating to this problem?
JUnit’s clever assertEquals method
I ran into a feature of JUnit the other day that is very useful, and a neat touch for the developers to put in; it really shows the authors’ attention to detail.
JUnit, for those uninitiated, is a unit testing framework for Java. JUnit provides a set of statically available assertions you can invoke within your test cases in order to ensure that your software is behaving as you think it should. They are accessible from the org.junit.Assert package and can be statically imported as follows:
import static org.junit.Assert.*;
This allows you to reference the methods without prefixing them with Assert; in other words you can call assertEquals(Object first, Object second)
as opposed to Assert.assertEquals(Object first, Object second).
Anyways, JUnit provides a whole raft of assertEquals methods, overloaded for different types. I was pleasantly surprised to see that JUnit is clever enough to provide a ‘diff’ed output when the assertions fail. This makes it much easier to see where the failure occurred, as the difference in output is highlighted and obvious. Here are some examples:
import org.junit.Test; import static org.junit.Assert.*; public class AbsoluteTest { @Test public void testStringAssertEquals() { assertEquals("Hello","hello"); } @Test public void testArrayAssertDifferingLengthEquals() { assertArrayEquals(new int[]{5,7,8,10},new int[]{5,7,8,9,10}); } @Test public void testArrayAssertSameLengthEquals() { assertArrayEquals(new int[]{5,7,8,10},new int[]{5,7,8,9}); } }
Here is the output:
Note that I used assertArrayEquals as opposed to assertEquals for the arrays; doing so compares arrays and their elements rather than just reference equality. Here is the same test with the method switched:
This is because the assertEquals method that takes two objects merely invokes the standard reference equality on the objects, and gives the toString representation of the arrays when they fail. Final little tip that relates to the previous point: if you ever need to print out the contents of an array in Java, Arrays.toString is your friend.
int[] array = {5,6,2,17,55}; System.out.println(array); System.out.println(Arrays.toString(array));
Results:
[I@744a6cbf [5, 6, 2, 17, 55]
The Arrays class has a lot of useful utility functions when working with arrays, including toString, and equals.
Minimum to know about dates and time in Java
Please avoid coding the following method. It has no effect and demonstrates a lack of understanding of Date and Calendar.
// BULLSHIT CODE! This method does nothing. public static Date convertTz(Date date, TimeZone tz) { Calendar cal = Calendar.getInstance(); cal.setTimeZone(TimeZone.getTimeZone("UTC")); cal.setTime(date); cal.setTimeZone(tz); return cal.getTime(); }
Odi has a great explanation of the bare minimums you need to understand about dates and times to make useful, real world applications. The examples concern Java, but similar concerns must be taken in other languages as well. Highly recommended reading.
Divvy
If you’re using a Mac, you owe it to yourself to try a great program called Divvy.
In a nutshell, Divvy lets you divide up your workstation as you see fit, without having to manually resize all the windows yourself. For instance, at work I have two workspaces; one for Mail and Calendar split 50/50, and one for Terminal, NetBeans, TextMate, and FireFox, with Terminal and FireFox taking the largest space. Manually positioning four windows without leaving gaps is nigh impossible, and time consuming to boot. I bind Divvy to Ctrl + Shift + Spacebar, and can position all 4 windows just how I like in just seconds.
Protip: Hold down the command key while dragging to get a finer grid.
Protip #2: You can set keyboard shortcuts for different divisions of the space. Press the little gear icon in the top right of the program and go to the Shortcuts tab.
Please rethink “required”
It really bothers me to have to remember dozens of logins and passwords to all the sites I may want to use on the Internet. I appreciate when sites take time to use OAuth or Twitter/Facebook login integration, so I don’t need to make yet another account, for which I’ll forget the login, have to be sent a reminder the next time I want to use it, reset the password, and start all over again. Lest you think I’m a senile 23-year-old, I’m talking about sites I visit infrequently like certain forums, where in the midst of researching some programming issue I’m facing I stumble back onto the site. Invariably these sites require registering and logging in to make comments; I can understand this need from a spam avoidance perspective (though even with CAPTCHAs and logins, a dedicated spammer is still going to get through), but from a user-interface perspective, it’s a big pain.
As a realist, I understand that the situation’s not going to change any time soon. So I’m resigned to having to sign up for a site just to make comments on it. But what I really cannot abide by is the absolute ludicrous amount of information you have to submit in some cases.
Case in point, there’s a very good article on Pitfalls in Scala on the Java Lobby. I was going to comment, and got into the whole registration thing. Well, have a peek at the information Java Lobby expects you to provide just to be able to make a comment on their site:
I’m surprised they didn’t have a field for your social security number; I mean that’s probably pretty crucial for them to know if they’re going to let you comment on their precious articles, right?
There’s a lot being said about privacy today in the wake of Facebook’s changing policies, but I don’t hear so much complaining about sites requiring way more information to signup than necessary. Let me know in the comments if this bugs you too.