Archive for the ‘Development’ Category
I was inspired this week by a post on the Rails Google Group by Melvin at 48hourlaunch.wordpress.com, who was asking for suggestions on a software problem to tackle with 48 hours of effort.
I’ve got what I call a “magic notebook”– several, to be precise– full of app ideas in various stages of ideation. So I decided to take on this challenge as well and see what I can do with one of them.
Like Mel, I’m taking on a project that meets one of my immediate needs and is well within my area of expertise. So I’ll be creating something that is useful to me and also has a broader market appeal.
One of my defining characteristics is the inability to do things halfway; unfortunately, this can sometimes manifest as “analysis paralysis”, overengineering, etc. Although Rails inherently short-circuits a lot of these tendencies (as does my business partner, for that matter!) the strict time limit I’m putting on myself makes this something of a competition between completion and perfection. At worst, I will move one of my unrealized applications one step closer to market, and hopefully learn something about my internal process along the way.
So what’s the big project going to be? Can’t talk about that yet, but if all goes according to plan there should be something public in within the next 30 days (48 hours / 2 hours per day = 24 days). I’ll also be posting notes about my progress as I go.
One of Internet Explorer’s famous shortcomings is its lack of native support for transparency in PNG images—one of the very characteristic that makes PNGs so appealing to begin with. Here’s how to incorporate transparent PNGs into your site in a way that all browsers will handle, using only Cascading Style Sheets (CSS).
1) The Approach
We’re going to put each image into the document twice: once in a way that Internet Explorer will understand, and once in a way that standards-compliant browsers can understand. In both cases, we’re going to use an appropriately classed <div> element:
<div class="png_standard<img src="my_graphic.png" width="150" height="294"></div>
<div class=”png_ie” style=”width=150; height=294; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=’my_graphic.png’, sizingMethod=’scale’);”></div>
This results in one image and an empty <div> showing up for Firefox and Safari, and two images (the first without transparency) showing up in IE. Note that you must specify the height and width of the image in the style tag of the png_ie <div>!
2) The Following Line is True. The Preceding Line is False.
Now we’re going to use CSS selectors to only show the <div> that’s appropriate for the browser. It’s crucial that these CSS rules are included in your style sheet in the order presented!
We’re going to take advantage of a non-standard CSS selector that only IE recognizes: * html.
div.png_standard {display: block;}
div.png-ie {display: none;}
* html div.png_standard {display: none;}
* html div.png_ie {display: block;}
Read from top to bottom, these rules state:
- Display any <div> with class=”png_standard” in the normal way.
- Do not display any <div> with class=”png_ie”
- If you are IE and can read this, hide any <div> with class=”png_standard”
- If you are IE and can read this, show any <div> with class=”png_ie”
3) The Last Step
Actually, there is no last step That’s it! For standards-compliant browsers, the <div> containing the transparent PNG is displayed normally, and the <div> containing the ugly IE code is hidden away. For IE, the <div> that it does not understand remains hidden, and it renders the <div> that forces it to recognize PNG transparency.
Transparent PNG in Internet Explorer for Windows:
And in Safari for Mac OS X:
4) Sample Code
Assuming that you have a PNG named my_image.png, the following page will render appropriately in all browsers:
<html>
<head>
<style type="text/css">
div.png_standard {display: block;}
div.png-ie {display: none;}
* html div.png_standard {display: none;}
* html div.png_ie {display: block;}
body { background-color: #bdbdce; }
</style>
</head>
<body>
<div class="png_standard"><img src="my_graphic.png" width="150" height="294"></div>
<div class="png_ie" style="width=150; height=294; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(
src='my_graphic.png', sizingMethod='scale');"></div>
</body>
</html>
From the description for Acts As Enterprisey:
Rails make life easy for us but– and it’s a big but– we don’t want it to look easy. acts_as_enterprisey is your friend. How does acts_as_enterprisey make webapp development look hard? Well, the only way your client can judge your app is by playing around with it. What better gives the feeling of heavy weights being lifted behind the scenes than slow response times? Exactly. That’s what acts_as_enterprisey does.
Simply insert acts_as_enterprisey in your ActiveRecord model [and set the delay to whatever value you want.] So while your client clicks, …waits…, and then gets the page, you can blather on heroically about wrestling with clustered indexes, cache expiration strategies, n log n seek times, etc ad nauseam.
Clients pay you to solve their technical problems. They want to feel like they’re getting their money’s worth. Especially after you start submitting enterprisey invoices.
So make their wishes come true: it’s only fair. Ethical, even. Crank the delay up as the deadline approaches, make them sweat, display fortitude and perseverance, etc. And when they can’t take it (the app’s sluggishness, your bills, whatever) any more, [remove] acts_as_enterprisey from your models and book the flights to Vegas.
This is akin to the infamous “make_it_go_faster” flag. Yay.
I’m currently working on a project to create a travel website, and I needed to have a bunch of member profiles to use for testing the member directory. I came across a great Ruby gem called Faker which I’ve used to create the dummy accounts.
Installation is easy, of course: gem install Faker
Next, I created a Rake task for populating the accounts:
namespace :db do
namespace :development do
desc "Create user records in the development database."
task :fake_user_data => :environment do
require 'faker'
@countries = ["United States", "Canada", "United Kingdom", "Germany", "Mexico"]
@genders = ["Male","Female"]
@privacy = ["members", "public"]
def randomDate(params={})
years_back = params[:year_range] || 5
latest_year = params [:year_latest] || 0
year = (rand * (years_back)).ceil + (Time.now.year - latest_year - years_back)
month = (rand * 12).ceil
day = (rand * 31).ceil
series = [date = Time.local(year, month, day)]
if params[:series]
params[:series].each do |some_time_after|
series << series.last + (rand * some_time_after).ceil
end
return series
end
date
end
100.times do
u = User.new(
:first_name => Faker::Name.first_name,
:last_name => Faker::Name.last_name,
:birthdate => randomDate(:year_range => 60, :year_latest => 22),
:created_at => randomDate(:year_range => 4, :year_latest => 0),
:city => Faker::Lorem.words(1).to_s.capitalize,
:state => Faker::Address.us_state(),
:country => @countries.rand.to_s,
:password => “greatpasswordhuh”,
:password_confirmation => “greatpasswordhuh”,
:accepts_terms_and_conditions => true,
:gender => @genders.rand.to_s,
:email => Faker::Internet.email
)
u.extended_profile = ExtendedProfile.new(
:bio => Faker::Lorem.sentences(5).join(” “),
:occupation => Faker::Lorem.words(1).to_s.capitalize
)
u.preferences = Preferences.new()
u.save!
end
end
end
end
Note that while Faker was good for creating random names, e-mail addresses, etc., I needed some other data that was outside of its scope, for example gender and country. For these, I simply created an array (like @genders = ["Male","Female"]) and called @genders.rand to pick a value. I also used its Lorem Ipsum generator to create random city names, occupations, and biographical text.
Once the Rake task was written, it was simply a matter of typing rake db:development:fake_user_data to populate the database with my junk records. Pretty sweet!
You can find Faker at http://faker.rubyforge.org/.
I finally finished migrating everything over from my old desktop to my new iMac. (I’m still amazed that a consumer-level Mac is more than twice as fast as my old high-end desktop… such is the pace of hardware, of course.)
At any rate, when I started working on one of my Rails projects, I was surprised to see that performance was really poor– much slower that on the old box. Then I realized that my Ruby and Rails installations probably got migrated by Migration Assistant.
Sure enough, ruby -v in Terminal revealed Ruby 1.8.6 for PowerPC/Darwin. This means that Ruby is running in PPC emulation, which explains the performance I was seeing.
Since Leopard ships with Ruby, this means that I now have two versions: in /usr/bin/ruby there’s the version that came with the OS, which is
ruby 1.8.6 (2007-06-07 patchlevel 36) [universal-darwin9.0]
In /usr/local/bin/ruby there’s:
ruby 1.8.6 (2007-03-13 patchlevel 0) [powerpc-darwin8.10.0].
This is obviously a problem…
Some Google time later, I came across this post on Punctuated Productivity; that set me in the right direction for uninstalling the old version and getting the new one up to snuff. His approach was to completely wipe /usr/local/bin and /opt/, which I found a little scary. Here’s a slightly more surgical approach.
- Remove the following from /usr/local/bin (sudo, of course):
gem*
update_rubygems
rails
rake
mongrel-rails
cap
capify
gpgen
index_gem_repository.rb
libpng-config
- Unfortunately, I had just installed and configured ImageMagick on the old box, which is a long and tricky process that I’ll have to do all over again. But since it was the only thing that I had installed on that day, so I was able to
open ./ to open /usr/local/bin in the Finder, sort by date, and select/delete all of the ImageMagick and RMagick files in a couple of clicks:
Magick-config
Wand-config
animate
compare
composite
conjure
convert
display
freetype-config
identify
import
libpng12-config
libwmf-config
libwmf-fontmap
mogrify
montage
pkg-config
stream
wmf2eps
wmf2fig
wmf2gd
wmf2svg
wmf2x
libpng-config
- My last uninstall step was to delete /opt after all, because only MacPorts (which I used to install ImageMagick) had put anything in there.
Now hash -r followed by which ruby correctly reveals /usr/bin/ruby, and ruby -v reports ruby 1.8.6 (2007-06-07 patchlevel 36) [universal-darwin9.0]
Now to reinstall Rails:
sudo gem install rails --include-dependencies
Next I have to reinstall ImageMagick and RMagick, which will hopefully be less painful this time around now that I know about MacPorts…
Shameless self-promotion: a friend of mine who is an ardent Obama supporter and active Something Awful forum goon recently contracted me to build a blog site for her. The result is “The Audacity of Truth”, a site devoted to dispelling media myths and mud-slinging centered on Obama. The Something Awful community regularly posts there, and together they have raised over $15,000 for the campaign through the site.
Check it out at www.audacityoftruth.org
A few years back, I started working on a JavaScript framework for developing 100% portable, client-side web applications. This actually arose out of some contract work that I had done in which I needed to create a fully interactive prototype for an interesting piece of desktop sotftware. The software was intended to monitor one or more human organ transport devices, providing a real-time view of the system’s state and issuing warnings as needed.
Although the framework had been previously available as a download from idolhands.com, it’s finally matured enough (and grown complex enough) that I’m releasing it under the Lesser GNU Public License. The code repository is on Google Code and I’m working on documentation and a sample implementation now. The framework has been renamed FACETS, for Fat Ajax Client / Thin Server.
They did the right thing!
Tonight when I got home from work, I found this in my e-mail box:
Apparently, Apple used to provide video of WWDC sessions, but last year, they opted instead for streaming broadcasts of the sessions via “ADC TV”. With no mention of session videos at this year’s WWDC, everyone pretty much assumed the worst; for many, this was right up there with the quality of the food as a sign that the good old days days of the WWDC were long gone. So nay-sayers, say nay no more. Or something.
As of 12:45 this morning, there are 108 sessions available for viewing, with more sections labelled “Coming Soon”. Each session seems to contain an eBook of slides and a video of the presentation itself. (I’m not talking about what sessions are or are not there, because of the often-stressed NDA.)
Hopefully now that Apple has done the right thing and released all of this content, the dev community can take a deep breath and get back to coding the next wave of great apps for Leopard. Mine is already in progress…
I’m a 13-year veteran of web development (currently doing WebO) but a complete newcomer to Cocoa. Since WWDC I’ve been tackling learning Objective-C. I learn best by doing, so I thought up a little app that I could write while learning the language.
I was sitting on the porch having a cigarette, staring at my notebook and trying to figure out my object model. I was really afraid of making the wrong choice with the “isa” hierarchy and ending up with a really kludgy model. “Isa” doesn’t express relationships the way I want to with my application’s entities.
If this were a web app, I would have separate database tables for each entity, and lookup tables mapping the relationships. In the web app these tables would of course be represented as objects, and their relationships would be handled by the object graph.
But this isn’t going to be a web app, so how am I going to create that object graph with all of its relationships?
The term “Core Data” popped into my head, but I didn’t know anything about it other than the fact that it was featured in several sessions on the WWDC schedule.
A single Google search later, and I found an incredible tutorial by Scott Stevenson at Cocoa Dev Central called “Build a Core Data App“. The graphic in the header showed an entity diagram… and I knew that this was what I was looking for.
The tutorial walked me through creating a sample blogging app that has Topic, Post, and Author entities, each with attributes and relationships. The data modelling is done in XCode– which I didn’t even know was possible– and then the data model is available to Interface Builder to bind to the view.
At a couple of milestones in the tutorial Scott recommends building and running the application to see how things are coming. The first time I did this, I entered a few lines of random text and played with the interface before quitting and resuming the tutorial. The second time I compiled and ran the app… the data from the first run was still there. This freaked me out. Sure enough, there was an XML file in ~/Library/Application Support/BlogDemo/ with my junk data in it.
Core Data is going to make a huge difference in the way I approach Cocoa in general and my app in particular. I’m particularly grateful to Scott Stevenson for his clear writing and illustration.
Okay, so my post-WWDC, desktop-application-envy got the better of me. Since I learn best with a project in my head, my laptop at hand, and a book at my side, I’m now working my way through a series of Cocoa and Objective-C books.
I just finished the first in my stack, Learning Objective-C on the Macintosh, by Mark Dalrymple and Scott Knaster, available from SpiderWorks.
I’m a long-time O’Reilly fan, but despite being burned on occasion by poor editing and worse writing, I’m not as averse to buying outside of their catalog as I used to be. And it’s paid off this time: I’m really glad that I chose this particular book to start with.
I love the fact that the authors focus on the language, not the environment. Interface Builder isn’t covered until the very last chapter of the book, and there’s rarely even a mention of XCode itself throughout. The sample code that you start writing at the beginning of the book gets refined as new concepts are introduced, and there’s nary a user interface in sight.
The chapters are short and clear and tend to focus on single concepts, with a sample-code-to-copy ratio that makes reading easy and skimming easier. The chapter on memory management and the autorelease pool alone (reinforced in subsequent chapters) made the book worth the money.
Learning Objective-C on the Macintosh also features an appendix highlighting differences between Objective-C and other languages, intended to make things easier to understand for those who are learning Objective-C after having mastered another language like C, C++, or Java first.
Attentive readers may ask: what is the Cocoa project that’s in my head? Really attentive readers will know that I’m not gonna tell yet. Attentive readers who know me personally may doubt that any such project will ever see the light of day, but they’re not being nice. (Psychic readers: no spoilers, please.)
|
1 Comment »