Bugzappy's Blog

Switching over from Zend Framework to Ruby-on-Rails presents stumbling blocks. Rails wants to manage your database from A-to-Z. Fair enough.

But. When it comes to inserting data into it via rake db:migrate or rake db:seed (the latter being the correct way of managing your data separately from your schema), you may encounter outright frustration: Rails will not let you set the id of the records!

For example, you write

Singer.find_or_create_by_id(:id => 100, :name => “Donna Summer”, :rating => 2)

but in your database, Dona’s id is just 1, or whatever the next available AUTO INCREMENT number was. I feel love — not.

There are at least two solutions, that hinge on getting around the fact the id is a protected attribute. First one:

singer.find_or_create_by_id (:id => 100, :name => “Dona Summers”, :rating => 2) {|record| record.id = 100}

or you can make use of the attributes= method of ActiveRecord::Base in the following way:

Singer.attributes=({ :name => ‘Donna Summer’, :rating => 2}, false)

The false passed as third parameter means “do not protect the protected attributes”. The RoR API documentation puts it this way:

attributes=(new_attributes, guard_protected_attributes = true)

Allows you to set all the attributes at once by passing in a hash with keys matching the attribute names (which again matches the column names).

If guard_protected_attributes is true (the default), then sensitive attributes can be protected from this form of mass-assignment by using the attr_protected macro. Or you can alternatively specify which attributes can be accessed with the attr_accessible macro. Then all the attributes not included in that won‘t be allowed to be mass-assigned.

Look it up on http://api.rubyonrails.org/

Mike Nachbaur, who is a PhoneGap developer and contributor, made some significant inroads with the App Store review process, as it applies to code written on the PhoneGap framework. Thanks to his work and to the diligence of one of the application reviewers at Apple, one could say that PhoneGap has a solid, if informal, contact with Apple. If you have an interest in PhoneGap, read Mike’s blog post.

We eagerly await further news.

About 4 weeks ago I posted a blog entry with a long list of things to think about before exposing your code, data and CPU’s to the masses. My list is really written for people whose head is on the block if things go wrong, and is really concerned with “have you thought about all the categories of things that can go wrong?”

In this month’s FREE php|architect issue (available only in PDF), Eric David Benari provides a list of much more specific things to check on the implementation side. It almost sounds like “did you brush your teeth before going to bed?” (I say this in a good way), with things such as having your 404 and 403 pages set up properly, ensuring browser-side caching is specified correctly, serving data and files from RAM not from disk as much as possible, and more. It’s a useful list with good sample code, I recommend it to new web developers as an overview of what aspects of coding for performance deserve attention, and to more experienced coders as a handy cheat sheet.

Now for a bit of a critique. Some of these coding techniques will help a site’s quality a lot, but frankly, if you are testing, then you’ll find out about these issues earlier than at the time of going through the checklist. 

Others will increase your site’s performance by a lot, but if you are benchmarking your app to meet a specific demand, then you’ll know there is a problem (or not) before you look at the checklist.

What really matters is that (a) the way you’ve coded your app and deployed it, it will provide the expected quality of service, and (b) when you need to improve performance, you have a solid idea of how to do so (improve the code, re-code, add hardware resources.) The techniques outlined in Eric’s article are key to both.

So I’m going to stay with my more abstract checklists, along which I have very concrete toolboxes such as the “coding checklist” in Eric’s php|architect article.

At our company we have been planning to use phonegap.com to develop on the iPhone, for 3 reasons: (1) makes use of languages we already know well, (2) should save us development time, and (3) should help us target applications to multiple mobile operating systems (iPhone, Android, Blackberry). 

However recently Apple has rejected a number of phonegap-based apps — see Mike Nachbaur’s blog — needless to say we are concerned, and the phonegap people (developers and users alike) are bordering on outraged, and certainly scared. Mike Nachbaur did the right thing and sent Apple a politely written open letter, which they acknolwegded but apparently have not responded to yet.

Ajaxian complained, and ReadWriteWeb offered some potential reasons for Apple to be rejecting phonegap apps. Not least of which being that Apple may want to make cross-platform development more difficult than it has to be.

To us at Logimake this may mean the following:

1. Because our time spent learning and developing for the iPhone will not easily benefit our strategy on other mobile platforms, we will have to spend more time right now on Android and Blackberry (using phonegap, perhaps), to compensate for the loss of synergy
2. Because it is still not clear yet whether the iPhone will become a serious player in the enterprise, that loss of synergy is making it doubly imperative to develop on a Blackberry-enabled platform like phonegap. 

Apple’s forte on the iPhone is in consumer apps, and it has lots to prove in enterprise apps — and integration. By keeping cross-platform frameworks, and hence applications, at bay, Apple may be reducing its own potential success in the enterprise.

We are eagerly waiting any news from Mike or Apple.

We had a problem on some of our Macs where the iPhone simulator would not play videos that we encoded and embedded in an iPhone application that we built. However these videos would play just fine on their own, and also they would play just fine on a real iPhone, without any changes.

Apple support forum has some answers:

http://discussions.apple.com/thread.jspa?messageID=8538445

Particularly helpful:

This fixed it for me.

I moved :
DivX Decoder.component
DivX Encoder.component

out of the directory:
/Library/Quicktime
The video player used to not play files that I encoded myself. Now it does.

Thanks 

ed.anisko

I did exactly that and everything worked fine. Note: I don’t use DivX so I cannot be sure that this quick fix will not break something important to you.