06.27.06

Make the Digg Homepage, Pass Go, Collect $20

Posted in General at 3:57 pm by matt

After listening to either an episode of This Week in Tech or Diggnation (not sure, probably both) where Kevin Rose talked about people trying to “game the system” by spamming diggs, I was curious about the motivation behind people trying to do that.  What’s it worth to them?

So, I researched the Digg Effect, and came across lots of articles, but two really good ones stood out.  First, Digg vs. Slashdot (or, traffic vs. influence) on kottke.org and second, The Digg Effect on hrmpf.com.

I wanted to know how much traffic we’re talking about and how much revenue someone could expect to get from making the digg homepage.  Both articles come up with the same conclusion: digg sends traffic, but it doesn’t really gain you readers.  The latter article even says how much he made from being dugg.

So, if being dugg doesn’t gain you long term readers, then the monetization can only be from the initial pop.

The “The Digg Effect” article was in reference to an article that was dugg titled, “Apple invents 1984’s telescreens, 22 years too late- Oh, the irony!” — The digg link is bad, but I found the original article here. It’s from January.  The author later states that he made about $10 dollars from being dugg.  I took a look at digg’s alexa graph, and since January, they’ve roughly doubled their traffic.

So, I say, being dugg is worth $20 dollars.  Do you hear that Kevin?  If you were unscrupulous, you’d mix ads in with the stories, but I don’t think you are, so I’m not worried about that.

Anyway, the initial articles both said that the digg effect was very short term.  The kottke.org article talks about how slashdot traffic created a more sustained readership for him.  The hrmpf.com article, well, I’m not sure if that was ever slashdotted, so take this with a grain of salt — I checked alexa’s daily pageviews for hrmpf.com, and noticed something.  Before he was dugg, he was pretty much at baseline.  After that, his traffic drops off to a small fraction of the digg-effect traffic, but it stays above baseline.

What I’m saying is, maybe he didn’t get 15,000 new readers, but quite possibly, he gained some, and that’s worth infinely more than actually being dugg.

If being dugg is worth $20 directly, well, there’s not much motivation to being dugg.  If being dugg gets you a large number of incoming links and an increased readership, well, you’ve got the makings for some recurring revenue directly from your readers and an increased pagerank for more search traffic, both of which, over time, could be worth much more than $20 bucks.

I view making the homepage of digg as, well, nothing earth shattering, but definitely something that can help a small blog build a readership for the long term.

technorati tags:, ,

Blogged with Flock


06.26.06

Damn Interesting

Posted in General at 10:25 pm by matt

Damn Interesting has got to be one of the best websites out there, to me.  It’s well written, esoteric, and intellectual.  I mean really, just about every single post there is totally Digg worthy.

I can’t believe there aren’t ads there.  I’d click on them all the time just cause i like the articles so much.

technorati tags:,


06.22.06

Multiple scopes with validates_uniqueness_of in Rails

Posted in Programming at 3:24 pm by matt

Previously, I talked about Validates_uniqueness_of and scope in rails

Well, what happens if you’ve got a case where, say you’re selling widgets, and you’ve got a join model set up with has_many :through relations, and you’re working with the following table:

(we’re listing stores that sell our widgets, and what size and price they sell them for)

Table: saleitems

Columns: widget_id, store_id, size, price

So, now, we want to validate that a widget can be sold at any store, and a widget can be sold many times at one store, but we can only sell a widget-store-size combo once. (You can’t sell a LARGE widget twice at the same store)

I think I was wrong, previously in my understanding. Now, I’ve written some code and see that you do the following:

You add a “validate_on_create” function to your saleitems model, and it looks like this:

def validate_on_create
   if Store.find_by_widget_id_and_size_and_store_id(widget_id, size, store_id)
   errors.add(‘you can’t do that’)

end

Thanks to: Rails Weenie for the answer

technorati tags:, , ,


06.19.06

Five Bad Reasons not to use Ruby on Rails

Posted in Programming at 5:33 pm by matt

I’m long term PHP developer, and I’ve recently started using Rails.  No, wait.  I was pretty much a deeply entrenched long term PHP developer, and I’ve recently been converted to the Cult of Rails.  I’ve been writing PHP since 1997, back before it had its very own recursive acronym and was called PHP/FI (Personal Home Page / Form Interpreter).  I’ve used it on many, many projects, and I’ve gotten pretty good at making it do whatever the hell I want it to.  If you’re a programmer, you know this concept.  Once you work with a language enough, it becomes second nature — you don’t have to look things up, and you don’t have to think about the tools, you think about what you’re doing, and that makes you a whole lot more productive.

So, I also keep up with things in this Web 2.0 internet world.  I know how to wield Prototype and Scriptaculous, and Model View Controller (MVC) is nothing new.  There’s lots of fanfare about how Rails “brings everything together” and is “omg so great.”  I took some of it as zealotry and the rest as people new to doing web apps finding a tool that’s better, than, say, ColdFusion. (Note: I hate ColdFusion)  Part of this is because so many designers are doing coding with Ruby on Rails.  So, I’ve been watching from the sides, but I haven’t actually gotten into Rails.  Why?  I’ve written a list.  I think a lot of developers would be served by reading this
list and taking home some of the points.  Anyway, here goes.

Bad Reasons not to use Rails:

1) It’s not PHP or your other alternative favorite language.

This is huge.  There’s just something that feels wrong about having to look up how to print to the screen or write to a file.  It’s been so long since many of us have had to read a manual for anything but, “Oh, what’s the syntax on that command again?” that we’re uncomfortable having to do it again.  This is essentially supreme laziness.  You don’t want to learn something new (Ruby), so you’re going to come up with excuses not to.  Let me tell you something: In this business, you either keep learning new things or you become irrelevant.  Ruby is not a weird language.  You will not have a hard time with it.  Just get a good syntax guide and keep it handy.  I promise you, Ruby is not hard.

2) But I don’t have to learn Ruby, I can just use Symfony, CakePHP, PHP on Trax, or the like.

I tried this, see.  This was my excuse not to learn Ruby — “I’ll just use a Rails Clone,” I told myself.  Well, blearg to that.  I actually tried three of them before trying rails, and let me tell you something: none of them compare.  Whether it’s features or documentation, none of them are really there yet.  These kinds of flexibile MVC/ActiveRecord style frameworks are still in their relative infancy, and Rails in 6 months is going to be 6 months better than it is today.  The other projects are months and months behind Rails, and in 6 months, they may not even be to where Rails is now.  Especially with documentation.  ESPECIALLY WITH DOCUMENTATION.

Rails does not have good documentation.  This means that the other guys’ documentation is horrible, horrible crap.  Also, Rails has several books, which basically gives you somewhere to go when you need help.  There’s no CakePHP book.  There’s no Symfony book.  Developers of other projects: If you want traction, you NEED documentation.  Orders of magnitude better than you have now.  Person considering Rails:  you need documentation.  Seriously, for something as big as this, you can’t just fiddle around, you’re not writing it yourself, and it’s a huge pain in the ass to look under the hood every 10 seconds — if you can even find what you’re looking for.  Rails does a lot of things for you, and you have to know what keywords to type where.  You need docs.  Good ones.  This goes for any big framework system.

3) I tried, and it’s complicated.

We’re starting to get to something resembling real problems, now.  Yes, you’ve tried using Rails, and yes, it CAN be daunting.  You have to do things “The Rails Way” many times, if you want to actually benefit from the framework rather than fight with it.

First and foremost, the biggest thing you have to accept is ActiveRecord.  Basically, for me, this means that I have to think about my database structure a little bit.  You’ll probably have to learn how to use something called join models, and you’ll have to learn about “has many through,” which is how you bend ActiveRecord to do your bidding in many cases.  However, the biggest thing for me was getting away from the notion I had in PHP coding of making one FILE that included other files and could be called directly.  Rails hides all of this from you.  There’s one “entry point” into the system, and everything past that is all “pretty urls that get parsed and sent to code” so to speak.  You’re not writing pages anymore, you’re putting pieces together in a framework to build an application.  After a while, you get used to it, and it really does make you more productive.

4) Frameworks are not flexible.

You’re right.  Frameworks aren’t for everything.  However, if you’re like me, you’ll spend a LOT of time just getting simple CRUD (create, update, delete) going, writing some SQL by hand.  Even if you’re highly motivated and a fast coder, this takes a lot of time.  My point?  Even if you spend some time futzing around with bending Rails to your needs, you’ve got ample time to spare, because you didn’t have to do a lot of repetitive busywork.

Point two is — Rails is pretty damn flexible.  Most of my, “oh, i can’t do that in rails” moments are falling by the wayside.  As I become more familiar with rails, I learn more and what I had presumed were inflexibilities are really just gaps in my knowledge.  In other words, most of the so called inflexibility is more like, “I’d have to write code to do that…” Which is exactly what you’d have to do in any other environment.  It’s just that with rails, you get so used to having everything automated, you are reluctant to actually write any code.  Yes, that sounds horrible, and it’s partly because I’m still learning rails.

You see, with PHP and no frameworks, you’re essentially writing all the code yourself.  This is fine and dandy, and you can do pretty much whatever you want.  However, with rails, you have to do things within the framework.  You have to know where things go, how to add capabilities to the scaffolding that gets built for you.  In most cases, the framework isn’t inflexible, it’s that you have to have knowledge of the framework on top of knowledge of the basics (code, get, put, http, forms, html, etc).  You have to know a bit more, but you get LOTS in return.

So, inflexible? I dont think so.  Rails is still low-level enough to not put TOO much burden on you.  Extending a content management system like drupal could lead you to some inflexibilities.  Rails isn’t a CMS, it’s a framework for building web apps.  This is one time where a framework really isn’t locking you into that much.

5) It’s slow.

This is a problem with ruby on rails.  It’s interpreted.  There’s also another problem with an easy solution.  If you want to use rails with apache, you need to use either fastcgi or fcgid, both of which are kinda like daemons that run rails, keeping things running, so that when a user makes a call on the application, all of rails doesnt need to re-load.  This makes rails LOTS faster.  However, ruby is still an interpreted language, and it’s definitely NOT as fast as PHP + Zend + a good code cache.

This is probably the only good reason to not use Ruby.  However, 90% of your application will probably be just fine, and, if you really need to, you’ll be able to code up your whole app, then rewrite the hotspots in another language in less time than it takes to write the whole thing in PHP.

Additionally, there will probably be a Ruby compiler of some form out for use with rails at some point.  My guess is that at the pace the rails folks operate, we’ll see a ruby compiler out in less than a year.

If you need optimization NOW:

Anyway, one final thought.  I’m not giving up PHP, it’s still very useful.  However, I *have* drunk the rails kool-aid, and it tastes pretty good.

technorati tags:, , , ,


06.14.06

Flock is pretty cool

Posted in Tagging, Web at 2:57 pm by matt

So i’m trying out flock, which is a new web browser based on firefox.  It’s got support for blogging, photos, delicious, rss reading, etc.

it seems pretty cool so far.

when i first heard about the project, months ago, i was very dismissive.  I thought that they were making a useless tool, that nobody would ever need anything more than firefox.  now, after playing with flock for 30 minutes or so, it seems really damn good.  I see exactly their vision, and I want to see MORE of it.  I know they can do a lot more with this project, and I’m excited about it.

I’m even more excited that firefox will see it and incorporate some of the better features back into firefox, making IT an even better product.

technorati tags:, , , ,

« Previous entries Next Page » Next Page »