31–40 of 131 posts
Google cache for those who hit the "pageview limit exceeded" nonsense: http://www.google.com/url?sa=t&source=web&ct=clnk...
Never thought I'll see that on a google service. Thanks for the cache.
If Google can't figure out a way to monetize popular content targeted at a professional technical audience, something's very wrong.
The best idea I've seen for such situations is to let people trying to view the page buy an instant traffic upgrade on the site's behalf; I'd chip in 100x the costs to serve my single hit if I knew it would restore visibility for me and some others.
The help link is also uncharacteristically inept for Google -- it doesn't lead to an explanation of pageview limits, and searching [pageview limit exceeded] in the help area turns up only user questions, no official article on the topic. The third hit is this unanswered gem, from a popular site with AdSense that keeps going down due to the limits:
http://www.google.com/support/forum/p/sites/thread?tid=08f19...
Google cache for those who hit the "pageview limit exceeded" nonsense: http://www.google.com/url?sa=t&source=web&ct=clnk...
"5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)"
I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some point your code is going to become unwieldy and difficult to read.
I try to stick to the rule of having each subroutine consist of no more than a page of code (so that each subroutine can be seen all at one time, without needing to scroll). Often that leads me to break up the subroutine in to many other subroutines. This improves readability greatly and makes it much easier to reason about the code. If any of the subroutines I break my code out in to happen to be reusable, that's just icing on the cake, not a necessity.
Earlier quoted context omitted.
Never thought I'll see that on a google service. Thanks for the cache.
It's fairly ironic--Google is restricting the page views (to limit bandwidth usage), but at that same time they're hosting a copy in cache of that same page, with no limits.
Because otherwise, Google 2009 == GeoCities 1999, and that would be unthinkable.
Google cache for those who hit the "pageview limit exceeded" nonsense: http://www.google.com/url?sa=t&source=web&ct=clnk...
wow, that's completely ridiculous. searching through their help center, they won't even tell you what the limit is, but it seems to be pretty low. just. wow.
The author lists the following as a symptom of being "unable to reason about code": "5. 'Bulldozer code' that gives the appearance of refactoring by breaking out chunks into subroutines, but that are impossible to reuse in another context (very high cohesion)" I disagree with this. The purpose of breaking out code in to subroutines isn't only for code reuse. If you don't break out code in to subroutines, at some poin…
I think what the article is suggesting, though, is not just that the subroutines would be "reusable" as in useful if called from another part of the program.
He's suggesting that the contents of each subroutine should be decoupled from each other - so not sharing global state, depending on strange changes made in other seemingly unrelated methods, etc.
The property of "I could reuse this routine if I needed to" implies low cohesion and therefore (probably) more maintainable code.
Steve Yegge argued something related to this topic that I don't think I like much, and I don't think you'd agree with it either. He claimed that junior programmers tend to write shorter methods because they're not used to fitting large chunks of complex code in their heads: http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm...
As someone who has seen 2000-line long C++ methods written by "senior developers", I still think short clearly named methods are better. :)
I'm skeptical of these lists because people can work through things. For example, the stuff listed under "Inability to determine the order of program execution" is something that many people will get jammed on eary on as they try to take their brains (which is honed on the syntax of school level maths) into the programing world (where equals is an instruction rather than an assumptions). Another one is "Lisp is opaqu…
The inability to determine the order of program execution is what made me give up haskell for ocaml and scala. Does that make me a bad programmer?