KDBDallas

Recently I was doing some performance stress testing on my upcoming iPhone app, Newsprint, and ran into a little Core Data gotcha that I thought I would document for both myself and for Google to index for others.

Special thanks to Jeff LaMarche for guiding me in the right direction to figure this out. You can find his blog at: http://iphonedevelopment.blogspot.com/

This issue came to play when I needed to do a fetch request from Core Data and then run a couple of Predicate “searches”/”filtering” on the data.

My original thought was that doing a single fetch request and then running my different predicates on the returned set of objects would have better performance then doing multiple fetch requests since I would only have to pull from the Core Data SQLite DB once and then I would have everything in memory and I could just simply manipulate it.

Turns out that this is HIGHLY incorrect.

If instead you just do multiple fetch requests and implement your predicate into your fetch request, that Core Data and SQLite are smart enough to scan the records more efficiently and without causing Core Data Faults to fire.

This gives a MASSIVE speed increase!

So if you are ever doing something similar, make sure to check this method and see if it to can speed your app up.

In the today’s world of software I think it is safe to say that the majority of applications offer some type of demo or trial.

For example, I offer a fully functional trial of iDeskCal for 14 days.

There are many different ways a developer/company can do/offer demos/trials.
I am not going to go into all the different ways and their pros and cons (perhaps I will in another post later).
What I want to talk about today is one thing you should NOT do no matter how you choose to implement your demo/trial.

The inspiration for this post comes from a real world experience that I had recently when trying out a trial from a company, who will remain nameless as this post isn’t about blasting them but instead educating developers no matter what platform they write for.

Recently I needed to try and recover some accidentally deleted photos.
I found an app that seemed to be exactly what I was looking for, and was excited because they offered a trial version with the statement that you can find out if their app can restore your files before you pay for the app.
I say I was excited because from my experience backup and recovery applications are ones the tend to break my rule above about most offering trials.
As I was searching a 1TB drive it took 13 hours to complete the search.

It is at this point that the app gives you a list of pictures to view and select to restore, so I started selecting items from the 70Gig worth of images it found (which took a while).
I hit restore forgetting that I was still in trial mode, at which point the application reminded me that to restore I needed to purchase a license.

Up to this point everything with the trial was fine.
There are some things they could have done to make it even better, but in general it was fine.
But this is the point where it took a face dive as well.

I am redirected to their website, as expected, and I purchased a license.
After purchasing I was expecting to get a serial number or registration file, but alas no….

It was at this point (and ONLY this point) that I was informed that the trial application executable was ONLY a trial executable.
I now had to download their app a second time, this time without limitations.
Which meant that after running for 13+ hours I had to lose everything I had done.

This is the main point of this post.
Let me say this clearly and to the point….

DO NOT DO THIS!

Now that were clear, let me explain the reasons why you should not do this.

Lets start with the general aspects that apply to any program.
Firstly, there is no reason to make your customer download your program again.
By them purchasing you should be making their life easier not harder.

Secondly, depending on your programs focus there is a good chance that a large amount of your customers are not going to be geeks.
In fact the opposite is more likely to be true.
Chances are that most of your customers will the type that know just enough to get around, or less!
This means any extra steps in your process adds to the chance for confusion.
This is bad is very which way, as it frustrates the user who is likely to make that frustration known to others, as well as increases the chance that you will receive a support request, which if you are a small development shop means you have to stop coding to respond to the support request.

Last yet most importantly, If your program lets users do any kind of data manipulation give the user a way to save that data, so by purchasing they do not lose anything they did in the trial.
If your trial doesn’t let them save without purchasing, then you REALLY should not be having separate executables.
At VERY least give them the ability to save into a proprietary file format, that you can go as far as encrypting if you need/want.

Along with this, make sure that the user can Open that saved data after installing the full version.
I was stung with this as well.
I was able to save my 13 hour search results, but when I tried to open them in the full version, the app would just crash no matter how many times I tried to open it.

Whatever you do just make sure they do not lose their work/changes!

So in conclusion, when coming up with how to do the trial for your program try and make the process as smooth as possible.
Try and make it so the user has to do a little work as possible.

Remember: Don’t screw over your paying customers just to try and keep your app from being pirated.

The book that I was the Technical Editor for, Cocoa Touch for iPhone OS 3, is now shipping from Amazon.com and should also be in (hopefully) most Barnes and Nobles.
View it at Amazon.com by clicking here.

This book is great for new iPhone developers as well as experienced ones.
You will need some Objective-C knowledge, but if you have some OOP (Object Oriented Programming) experience you should be ok with picking up an Objective-C book as well for as you work through the book.

If you are in a B&N stroll into the Geek, err, I mean Computer Programming section and look for the book.
Feel free to buy a copy to support my good friend and author of the book, Jiva DeVoe.
If you can’t get yourself to that level of geek, at least pick it up and look at the ‘Credits’ page, right before the Table of Contents and then you can go around to all the geeks in that area and say, “I KNOW THIS GUY!”

This makes 2 iPhone development books that I have been involved in, each one with more of a role than the last, however I can safely say it will be my last as after being involved with the book writing processes and having the author be a close friend of mine, I don’t really have a desire to write one myself (unless it’s an offer I just can’t refuse).

Today marks the end of an era…

Today we mark the end of GeoCities!

GeoCities was the premiere place to get your own personal “web space” back circa-1995.
GeoCities provide the initial playground for many of today’s web professionals (including myself).

I remember many-a-night hacking away on my GeoCities page.
Having informal feuds with others on who could do the best site with the latest and greatest web technologies of the times, like frame and guest books!

GeoCities has therefore always been, and continued to today’s closure, the ultimate place to find the worst looking webpages with the most crap and the worst code.

In honor of the closing I took it on myself to throw everything I know from doing professional web development for 12 years, out the window and come put together the following for your enjoyment.

This is a re-post of a blog written by Brent Simmons http://inessential.com/2009/07/17/on_that_moron_feeling. I am re-posting it as it is a great post.

I was a moron five years ago. Five months ago, even.

I’ve heard this from other programmers, so I don’t think I’m alone. They look back at old code they wrote and say, “What idiot wrote this crap?”

I used to wonder if this feeling would ever go away — as if I’d just get to the point where I’m super-awesome and that’s it.

But over the years I’ve learned to rely on this feeling. Were it ever to go away, then I’d be worried like hell. It would mean I’m not learning and not improving.

So, yes, I’m proud to have been such a moron so recently.

Post by Daniel Jalkut of Red Sweater Software – http://www.red-sweater.com/blog/825/getting-pretty-lonely. Reposting since Daniel’s site is currently overwhelmed.

This very post is delivered to your browser or news reader by the famous and fabulous WordPress blogging system. In my work as the developer of MarsEdit, I am exposed to countless blogging options, each with its own strengths and weaknesses. And yet, I stick with WordPress because it strikes a balance of power and ease of use which feels comfortable to me. Not to mention that Joseph Scott and others are tirelessly working to improve its API.

WordPress is licensed under the terms of the Gnu Public License (GPL) which, in a nutshell, stipulates that you are free to use the software however you like, but if you make changes and distribute those changes, then you must share those changes under the same terms. This simple, radical restriction means that you are prohibited from taking a GPL project and incorporating it with a closed-source project.

Violating The GPL

Violating the GPL is easy. All you have to do is write some code, intermingle it with some GPL code, distribute a changed copy of the original, and refuse to share your contributions. Bam! You’re toast. Assuming the original authors discover your violation and decide to pursue a resolution.

Once a violation occurs, it might be settled privately, or could escalate to legal court procedures. But the most obvious form of resolution is for the author of the changes to release their code to the public under the terms of the GPL.

Depending on how much code you “mixed” with the GPL code, this could mean only a small portion, or it could mean the entire source code of your project. This so-called “viral nature” of GPL is what scares the bejeezus out of companies, large and small, who fear the consequences of having to give up their own intellectual property to the public.

The terms of the GPL sound pretty simple at first read, but due in part to the epic consequences of a violation, there has been a great deal of debate and uncertainty about what legally constitutes a violation. Most of the debate seems to boil down to two questions:

1. What counts as a change to the original product?
2. What counts as distribution of those changes?

If you can legally justify that your additions to a GPL project either don’t change or derive from the original product, or haven’t technically been distributed, then you are not subject to the restrictive terms of the license.

Take GIMP, the popular GNU-licensed image editing application. The application supports plugins, analogous to the types of plugins you might find for the commercial, closed-source application Photoshop. A savvy developer may argue that a plugin doesn’t meet the criteria of changing the original application, because the original application still runs in its unaltered condition whether the plugin is there or not.

But promoters of the GPL take the position that plugins, by nature of being loaded into the same code space as other GPL code, do constitute a modification of the original, and are therefore subject to the terms of the GPL. As far as I know this is not a question that has been well-tested in courts.

Let me take a moment to make this abundantly clear: I respect the rights of authors to license their software under whatever terms they choose, including the GPL. In my opinion, all the legal mumbo jumbo ceases to matter once the original author’s intentions are made clear. So if the author of GPL-licensed code clarifies to me that it cannot be run on Sundays, then their GPL means it cannot be run on Sundays. But this is one of the problems with the GPL: its terms are not often understood, even by the authors of GPL-licensed code.

WordPress Themes & Plugins

WordPress supports two explicit forms of extension, each of which may affect the appearance and functionality of the product. Themes tend to work as a “skin” for the appearance of a blog, while plugins tend to introduce completely new features. Since plugins in WordPress are analogous to GIMP or Photoshop plugins, it would stand to reason that they would also be covered by the terms of the GPL. But what about themes?

Themes have been controversial in the WordPress community, as a few commercial business models have sprung up to take advantage of bloggers’ desires for high quality themes at an affordable price. One approach is to distribute “free” themes that contains commercial ads. So you might stumble upon the perfect theme for your blog, only to learn that the glaring “Brought to you by Hostess Cupcakes” line near the bottom of your page cannot be removed.

But the terms of the GPL, if themes are covered, would require that end users be granted the legal right to modify and redistribute their own copy of the theme. Zap the sponsorship, reupload to your site, and you’ve got a free, high quality theme with no ugly ads.

Today, Matt Mullenweg of the WordPress project announced his lawyer-supported opinion that themes are partly covered by the GPL:

I reached out to the Software Freedom Law Center, the world’s preeminent experts on the GPL, which spent time with WordPress’s code, community, and provided us with an official legal opinion. One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required.

If you’re starting with the understanding that WordPress itself is GPL, and WordPress plugins are GPL, then it’s not so much extra hay on the camel’s back, to also clarify that its themes are to some extent GPL. But it got me thinking again about my own blog, and about the restrictions the GPL imposes on the kinds of things I can do with the software that runs it.

GPL Stifles Participation

Now for the most controversial point of this article, where I suggest that the GPL does more to harm collaborative development than it does to help it.

For the purposes of this argument, let me reduce all the source code in the world down to three rough categories. I recognize I have omitted some classes of license here, but for the sake of argument, most projects fall into these camps:

1. GPL code. Changes may be distributed only in other GPL products.
2. Liberal-licensed code. (MIT/BSD/Apache/etc). Changes may be distributed anywhere. Appropriate origin-attribution may be required.
3. Closed-source code. May be distributed only by the copyright owner and other explicit licensees.

Now, there are a few people in the world who, for political or philosophical reasons, will only participate in a GPL project. And for compariable yet opposite reasons, there are some who will only participate in commercial, closed-source projects. But I propose that the vast majority of developers will participate in any project that is advantageous to them.

So let’s imagine a representative, run-of-the-mill developer who is working on a project that falls into each of these three camps. If this developer is not radically committed to their own project’s license, they will naturally look to outside resources in order to bolster the success of their own work.

As the developer evaluates communities to participate in, they must evaluate the legal impact such participation will have on their own project. The closed source communities are, by definition uninviting to outsiders. GPL communities are open and embracing of other GPL developers, but generally off-putting to liberal-license and closed-license developers. Only the liberal-license communities are attractive to developers from all 3 camps.

I know what some of the GPL-enthusiasts are thinking now: “leeches don’t count as community.” Many GPL developers take comfort in the fact that their hard work can’t be quietly taken and incorporated into a commercial product, without any payback of time or money to the original project. But you’re piloting an open source project, and the first step of building a community is to get people in the door. Liberal licenses? Whoo-eee do they ever get people in the door.

If you operate from the presumption that great developers love to build great projects, the first step in any successful open source project is to get as many great developers in the door as possible.

It’s Your Party

Yes, this is just me and my crazy theories. I haven’t done exhaustive research to prove that liberal-license communities thrive more than GPL communities. But the anecdotal examples are staggering. The very foundation of Mac OS X, the operating system through which I’m typing, is thanks to the liberally-licensed FreeBSD operating system.

Looking over to the right of my screen, I’m watching this sentence appear in a live web preview as I type, thanks to the WebKit project, whose liberal license makes it compatible with closed source projects such as Safari, as well as open source efforts such as Google’s Chromium project.

For years, the problem of a generic HTTP client library that runs on every major platform has been addressed by libcurl, whose liberal license has caused it to be embraced by countless companies and projects.

The popular Subversion source control system’s liberal license enabled Sofa, a commercial software business to contribute value to the community with its extremely polished, award-winning client application. Meanwhile, the newly popular distributed source control systems presents three major choices: git, Mercurial, and Bazaar. All are restrcted by the GPL-license, and therefore none is likely to inspire development of a Versions-caliber client.

I’ve touched the tip of the iceberg, and yes I’ve neglected to mention some GPL success stories such as Linux, MySQL, and gcc. These communities have thrived to some extent because the passions of the GPL community are strong, but we can’t know whether their success is in spite of the restrictions their license places on participation by the broader developer community.

Speaking of GPL succeses, WordPress is itself an example of monumental success. All of its developers have something to be immensely proud of. But whenever I am reminded that WordPress is GPL, my passion for it takes a bit of a dive. I’m more comfortable with the true freedom of liberally-licensed products. If a liberally-licensed blog system of equal quality, ease of use, and popularity should appear, my loyalties to WordPress would not last long.

It’s your party, and you’re entitled to write the guest list. But take a look around the room: not as many folks as you’d hoped for? Liberally-licensed projects are booming. Speaking for myself, a developer who has been to all the parties, I’m much more likely to pass through the door that doesn’t read “GPL Only.”

I have been back from WWDC for a little over a week now, but haven’t had a chance to say anything about it or post any pictures. (I will post an explanation shortly)

WWDC (Apple’s World Wide Developer Conference, in case you don’t know) was amazing!
This was the first time that I have been able to justify going (it’s not cheap) but man was it great.

I had the chance to meet so many amazing people that I talk to all the time on Twitter, but now I got the chance to meet them in real life.

Besides all the great developers and parties, it was a chance to learn about new and upcoming enhancements to the Mac operating system and the iPhone, as well as learn the best way to do certain things in code, coming from the people that write the language!

Apple also offers what the call labs during WWDC.
Labs allow you to take your code and sit down with an Apple Engineer that works on whatever particular topic you want, and they are there to serve. They will look over code and tell if you how you could have done it better, or they will help you debug an issue you are having, or anything else.

There is so much information flying at you all day that it can be overwhelming at times.

And when the sessions and labs end each day, WWDC does not end….
I have never seen more back to back, double/triple booked parties in my life.
Parties that go until all hours of the morning.

So with sessions and labs all day and parties all night, by midweek you are the walking dead but it doesn’t stop the fun. (and I didn’t even go out every night!)

Around the end of the week Apple throws a big party and this year had the band ‘Cake’ come and perform.

Overall it was a GREAT time and I can’t wait until next year, yet it is always nice to come back home to family as well.

We are talking about Nancy coming along next year and being able to tour San Francisco while I am in the sessions.

My WWDC 09 Photos – http://www.flickr.com/photos/kdbdallas/sets/72157620059169940/

I have been offered a gig of being the Technical Editor for an upcoming iPhone programming book.

The book is called “Cocoa Touch for iPhone 3.0″ and is being written by my friend Jiva DeVoe and published by Wiley and Sons Publishing.

You can visit the current pre-emptive webpage for the book at: http://www.wiley.com/WileyCDA/WileyTitle/productCd-0470481072.html

I was previously a Technical Reviewer for the programming book: iPhone SDK Application Development, 1st Edition

It will be interesting the see the differences between being a technical reviewer and a technical editor.

A while back I wrote another iPhone application that was mainly for myself, but the business side of me said, “If I wanted this app enough to write it, chance are there are people willing to pay a couple bucks for it.”

The down side of this was that I had to develop the application a lot more.
Instead of just having to be “enough” for me, it had to be complete enough to sell and for people to be able to easily use.

So I finished up making it great.
It was done and it was SEXY!

The problem…
The sexy part was the part that connects to your computer, and that part was Mac only.

I did not like the fact that it was Mac only because I knew it would really hurt sells.
So I bit my lip and went about redoing that entire section.
I wanted something that would feel familiar with but that was at least just homely looking instead of looking like a nasty skank.
The problem was that the way to do this was a pretty big undertaking as there was nothing standard for the iPhone and the doing a one-off is a huge task (hence why there is nothing out there).

Finally I found another developer who was in the final status of doing a one-off himself, and he agreed to let me have access to the code.

SWEET! Here was my answer, right? right?

So I went and integrated the code.
Problem was that the code was not complete, but that was alright because I still had a bunch of little things to finish up and I was under the impression that the other code would be finished shortly.

So I finished everything up, but still no updates on the other code…
CRAP!

So I started looking into the code to see if I could find where the problems were, but like I said before, this is a BIG undertaking of code and I had no insight of the under workings of that section.

However now all my code was done, so I needed this last part done.

Off and on I would spend a day or two digging into the code, and hitting up the developer for any word on updates.

Now 2 months after I finished my end, I was still in basically the same spot and still no word on anything anytime soon.

Finally last night I said, “screw this”, and I decided to go with the Skanky version for now, knowing that I could always go back if/when the other code gets finished, but just sitting here was doing no one any good.

Earlier today I finished the coding aspect of the new setup.
Then I just had to do a screencast help video and do all the paper work type stuff on the App Store.

Then it was off to the races!
Application SUBMITTED!

Now it’s just time to hope that it gets through the Apple review process, and quickly.

Oh and to be honest, this new way probably isn’t really Skanky, but it just kind of feels that way to me after my original design.

I have been finalizing the beta for iDeskCal 2.0 and in the process came across ChocTop.

ChocTop is a system for rapid mac software DMG packaging.

In setting it up and using it I found that it lacked a feature I wanted.
Mainly the ability to specify that it should you a Debug build instead of the standard Release build that you would usually use.
The reason for wanting a Debug build is simple… I am packaging up a Beta.

So even though I don’t know Ruby (which is what ChocTop is written in) I set foot to add this feature.
Luckily like most computer languages I was able to understand it enough to understand what was going on and enough to add this new ability.

Once I was done and used it myself, I sent it back into the developer and he has already integrated it into the repo version of the code.

If you are a Mac developer checkout http://drnic.github.com/choctop/