James Turner
James Turner, contributing editor for oreilly.com, is a freelance journalist who has written for publications as diverse as the Christian Science Monitor, Processor, Linuxworld Magazine, Developer.com and WIRED Magazine. In addition to his shorter writing, he has also written two books on Java Web Development (MySQL & JSP Web Applications" and "Struts: Kick Start"). He is the former Senior Editor of LinuxWorld Magazine and Senior Contributing Editor for Linux Today. He has also spent more than 25 years as a software engineer and system administrator, and currently works as a Senior Software Engineer for a company in the Boston area. His past employers have included the MIT Artificial Intelligence Laboratory, Xerox AI Systems, Solbourne Computer, Interleaf, the Christian Science Monitor and contracting positions at BBN and Fidelity Investments. He is a committer on the Apache Jakarta Struts project and served as the Struts 1.1B3 release manager. He lives in a 200 year old Colonial farmhouse in Derry, NH along with his wife and son. He is an open water diver and instrument-rated private pilot, as well as an avid science fiction fan.
Genomics and Privacy at the Crossroads
Would you let people know about your dandruff problem if it might mean a cure for Lupus?
Two weeks ago, I had the privilege to attend the 2013 Genomes, Environments and Traits conference in Boston, as a participant of Harvard Medical School’s Personal Genome Project. Several hundreds of us attended the conference, eager to learn what new breakthroughs might be in the works using the data and samples we have contributed, and to network with the researchers and each other.
The Personal Genome Project (PGP) is a very different type of beast from the traditional research study model, in several ways. To begin with, it is a Open Consent study, which means that all the data that participants donate is available for research by anyone without further consent by the subject. In other words, having initially consented to participate in the PGP, anyone can download my genome sequence, look at my phenotypic traits (my physical characteristics and medical history), or even order some of my blood from a cell line that has been established at the Coriell biobank, and they do not need to gain specific consent from me to do so. By contrast, in most research studies, data and samples can only be collected for one specific study, and no other purposes. This is all in an effort to protect the privacy of the participants, as was famously violated in the establishment of the HeLa cell line.
The other big difference is that in most studies, the participants rarely receive any information back from the researchers. For example, if the researcher does a brain MRI to gather data about the structure of a part of your brain, and sees a huge tumor, they are under no obligation to inform you about it, or even to give you a copy of the scan. This is because researchers are not certified as clinical laboratories, and thus are not authorized to report medical findings. This makes sense, to a certain extent, with traditional medical tests, as the research version may not be calibrated to detect the same things, and the researcher is not qualified to interpret the results for medical purposes.
Upward Mobility: Unit Testing Core Data
There's no reason to leave your database-centric code untested
One of the more common issues that arises in creating OCUnit tests in iOS is how to test code that uses Core Data. There are several challenges, but with a little foresight, you can be sailing right along.
The first issue that most people encounter is getting access to the managed object context. If, like most people, you’ve followed the code snippets that Apple provides, or followed a tutorial on the web, you hung it off the AppDelegate, and use
[[UIApplication sharedApplication] delegate]
to get a handle on the context when you need it. Alternatively, some people pass the context all the way down the view container chain, making it a property on each controller. I find this incredibly painful, and since most applications only have a single database instance open at once, there’s no reason not to keep the context around globally.
In any event, the problem with having your Core Data specific classes get the context from the sharedApplication is that when you run OCUnit tests, sharedApplication returns nil, and there’s no way to mock it. But, this is easily solved by creating a helper class that you use to access the context.
Read more…
Upward Mobility: Should There Be Only One?
Admittedly, the idea of Ballmer, Cook and Schmidt all battling it out Highlander-style is appealing...
As long as most people can remember, the smartphone space has been a contested one. Before the iPhone became temporarily ubiquitous, RIM and Palm were fighting it out to own the market, and today you have a plethora of platforms to choose from, including Android, iOS, Windows, and Blackberry. And because many mobile OS vendors license their products to third-party manufacturers, some mobile operating systems have little market share wars of their own, such as HTC fighting it out with Samsung and Motorola for the Android customer base.
I’ve talked before, in the context of languages, about the damage that the paradox of choice can bring to societies. Having more product choices may not make us any happier, or even lead to better products, but only create the vague uncertainty that whichever product choice we make, it wasn’t the correct one.
For obvious reasons, a monopoly doesn’t usually work out that well either, at least in mature markets with stable standards. Very few will argue that Microsoft’s most innovative years occurred during the period that they sat “fat, dumb and happy” with 90%+ desktop market share. But I would argue that there comes a time when some choices should be left to die a dignified death, and that both Windows and Blackberry mobile products are at that point.
Read more…
A Day at the 2013 Genomes, Environments and Traits Conference
In which the question of whether research subjects have any rights to their data is pondered.
The GET (Genomes, Environments and Traits) conference is a confluence of parties interested in the advances being made in human genomes, the measurement of how the environment impacts individuals, and how the two come together to produce traits. Sponsored by the organizers of the Personal Genome Project (PGP) at Harvard, it is a two-day event whose topics range from the appropriate amount of access that patients should have to their genetics data to the ways that Hollywood can be convinced to portray genomics more accurately.
It also is a yearly meeting place for the participants in the Personal Genome Project (one of whom is your humble narrator), people who have agreed to participate in an “open consent” research model. Among other things, this means that PGP participants agree to let their cell lines be used for any purposes (research or commercial). They also acknowledge ahead of time that because their genomes and phenotypic traits are being released publicly, there is a high likelihood that interested parties may be able to identify them from their data. The long term goal of the PGP is to enroll 100,000 participants and perform whole genome sequencing of their DNA, they currently have nearly 2,300 enrolled participants and have sequenced around 165 genomes.
Agile in name only
Agile isn't agile if you end up going over a waterfall at the end.
In politics, the term RINO is used to refer to a candidate who is “Republican in Name Only,” i.e., claiming the mantle of the party, but not conforming to the platform or belief system. In software development, there’s a similar phenomenon: companies that claim to embrace agile development principles, but really don’t understand agile. They’re Agile in Name Only (AINO).
I’ve written before about “waterfall with a crunchy agile shell,” the problem that if you are trying to control all three of the variables (time, features, resources), you can’t really do agile. Agile acknowledges the uncertainty in development estimates, and requires the team to stay “ready to ship,” so that when the decision is made to pull the trigger on a release, all the work done to date can be easily consolidated and shipped. But focusing on keeping shippable units in shippable shape only makes sense if you also embrace the idea of frequent releases, and putting only in the release what fits in the bucket.
In contrast, a company that’s agile in name only will cling to a distant release date and a laundry list of features, but still insist on short sprints and closing stories. At this point, the benefit of short sprints isn’t for the developers or the team, it’s for management, because it lets them focus on their burn-down charts, and chart the progress toward that eventual release that may be a year away.
Read more…
Upward Mobility: Automating iOS builds with Jenkins
If Jenkins is good enough for Apple to use, why not give it a try yourself?
One of the pleasant surprises I learned last year at WWDC is that Apple uses Jenkins to automate their iOS app builds. Since we were already using Jenkins to do the same thing at the Day Job, it was a nice confirmation that we had taken the right approach.
However, until recently, getting Jenkins to fire off an Xcode build, bundle it into an IPA, and sign it correctly was a real pain. Thankfully, in 2012, a Jenkins plugin for Xcode integration was released. It can be installed directly from the Jenkins plugin management page, and once installed, gives you a new build step called Xcode that you can add to a build.
William Gibson got some of it right
"Neuromancer's" technology still isn't here, but the dystopia is.
"Neuromancer," written 28 years ago, predicted a technological wonderland we're still waiting for. But its corporate dystopia is already here.
The overhead of insecure infrastructure
If we don't demand more secure development infrastructure, we get to do it ourselves.
The news is constantly full of companies and organizations falling victim to exploits. Software developers spend a great deal of our time defending against them. But why should they have to bother at all?
Developer Week in Review: Oracle's big bet fails to pay off
Google dodges a bullet, a new Perl in town, and GCC loses an OS.
Oracle fails to convince a jury that Google owes them big bucks, the annual refresh of Perl has arrived, and FreeBSD says goodbye to an increasingly restrictive GCC license.
Developer Week in Review: Oracle’s big bet fails to pay off
Google dodges a bullet, a new Perl in town, and GCC loses an OS.
Oracle fails to convince a jury that Google owes them big bucks, the annual refresh of Perl has arrived, and FreeBSD says goodbye to an increasingly restrictive GCC license.