sha90

This article is, quite simply, false. DSLR cameras have much superior sensors to consumer end cameras, including smart phones. The sensor makes an enormous difference in the photo; much moreso than the lens. Heck, I would be a 5D Mk III for the ISO improvements alone, forget the lenses. Unless you're doing something special that requires (a) zoom or (b) wide angle, the kit lens will do you just fine.

This guy is either a gearophile elitist or he's making referral money on those "pancake" lenses and the others he is casually "recommending".

It's not that it "doesn't belong in Thing", but rather, it can be performed by another entity. These are the same fundamental "responsibility" questions we struggle with in designing OO systems every day. When you have two or more entities collaborating on a responsibility, which one of them get the actual method? Incidentally, this is kind of what real life managers are for too, as much as we like to dislike them.

There are certain ... linguistic... reasons why Base appears in class names. It's important to understand the subtlety. In certain languages, especially those with packages or namespaces, you'll likely have a namespace Foo::Bar::Widgets where you put your WhateverWidgetWhatever classes. The package foo.bar.widgets.widget, or namespace Foo::Bar::Widgets::Widget, can look weird to some; it's also longer / less predictable, so you could potentially see them simply be called Foo::Bar::Widget::Base, which avoids naming duplication, and allows developers to not have to worry about plural/singular names.

Here let me help:

http://en.wikipedia.org/wiki/Sex-positive_movement -- "sex-positive" is a term describing a movement meant to embrace rather than repress sexuality. The play on words of "sex-negative" refers to the opposite of sex-positive, ie., sexual repression.

OP is saying that you are sexually repressed because sex jokes make you uncomfortable. This is a good point, because dongle jokes are actually not "sexist", they are simply sexual. Men hold no exclusive territory over dick jokes, or sex jokes in general. Women can tell dick jokes too. They can also joke about vaginas (Sarah Silverman much?) and both genders can appreciate the humour EQUALLY (yay equality!). Those who don't find it funny are NOT victims of sexism-- they are victims of a shitty sense of humour.

> It is tiring to translate thoughts, experiences, and feelings into a digestible and understandable format.

This is a very telling statement-- it's also somewhat ironic, given that one could easily interpret this as a passive aggressive jab at OP's "inability" to communicate. One could ALSO interpret this as a general sentiment about the importance of vocabulary. So either you did not communicate this point precisely enough, or you intentionally left it vague as some intelligent ploy to poke at the flaws in your own argument. I'll go with the latter cause it sounds more meta.

The actual issue is that it isn't about difficulty. It's actually impossible to translate thoughts in a predictable manner across racial, gender, and cultural lines. We are not machines, and so people interpret statements, and, in some cases, jokes, in the way that they are brought up to interpret them. In a victim-culture, jokes are usually interpreted as malicious devices. The problem here is that while some call for equality and understanding of other cultures/genders/races, this usually only applies to the cultures that are victimized. Equality is a two-way street, and understanding semantics is an important step to equality, because in order to respect, you must first understand. Just because culture/gender X makes a dongle joke, does not mean that culture/gender X meant the dongle joke as some insult to culture/gender Y, even though culture/gender Y might interpret it that way. We (all) have to put effort to understand things in the right contexts, so a dick joke between two guys (with no assumption that women are eavesdropping) is just that-- a dick joke between two guys-- it is not an assault on women (especially given the fact that it seems like it wasn't even meant to be heard by anybody else). Some leeway ought to be given to the interpretation of words, just as you should be reading the OP's text as it was intended, not simply as the words aligned on the page.

That said, I actually love how this very statement ties back to the original issue at hand so perfectly, even though it was some tangential argument about semantics, so thank you for pointing this out.

My only real concern with this essay is that the OP bothered to refactor out the duplication, but didn't bother to refactor his internal refactoring when it got too complicated, instead claiming: "look, now it got messy", threw up his arms, and said there's nothing more that can be done, blaming DRY as the culprit.

Except we CAN do something about it.

It would have been just as easy to continue refactoring the tweet_list() method to pull filtering, pagination, and profanity checking out into sub methods-- at which point you've built a strong reusable component that can support many more combinations of those extra requirements. So by the time you get more feedback saying, "we need a new page that only shows 5 tweets per page and hides profanity, but does not filter", you can now easily take that reusable component, pass in those options and be done rather than starting from the top because you refused to clean up your internals. That's why we strive for reusable components in the first place.

In other words, if the argument is that refactored code is messy, it really means you aren't done refactoring.

This timeline of events is inaccurate. _why's name was called out on a mailing list prior to the Slate article publication-- and prior to his vanishing. Please don't rewrite history in favor by pretending "he grew tired of the persona". He didn't quit because he wanted to move on with his life, he quit in a hissy fit because he was outed.

Open an issue for IAM roles in the GitHub issue tracker (http://github.com/aws/aws-sdk-js/issues). It seems like we want this, so opening an issue will give us all a better way to track the feature.

Method swizzling and refinements are basically the same thing. The real difference isn't in the features, it's in the fact that Ruby is a dynamic language, and Obj-C is only dynamically typed. You can swizzle all you want in a statically compiled program, and refinements work equally well in a "static" Ruby program. The problems with refinements start coming to light when you start refining things at runtime, i.e., with module_eval. Obj-C doesn't have this problem, since swizzling happens only once at compile time.

You could have said the same thing about Apple in the 90s.

Nobody is slinging mud for taking the site down temporarily. At least, without knowing the details of the attack, I don't think anyone is suggesting that there should have been zero downtime. The mud is being slung by those who don't appreciate a host dropping a client (paid or not) because of a single incident. That shows a complete lack of loyalty to your clients, again, paid or not. RM could have found a more reasonable way to drop pastie, if it really could handle the mix of takedown notices and network disruptions, but they didn't need to do it in the middle of the night with zero notice to the owner. Certainly they could have at least given him some time to migrate his stack and not have to leave all of pastie's users out in the cold --- not that it's such an essential service, but still...

"You mess with my customers"? So, pastie.org was asking for it by hosting a free-form data pasting site? Again, this is you acting like pastie.org is the one at fault and is responsible for a bunch of idiots deciding to saturate the line.

It seems as though you're skewing the issue here. And I think the real issue has nothing to do with whether pastie.org was a paying customer. I'd be interested to know if RM would do the same thing if there was no sponsorship arrangement and it was paying regular bills. My hypothesis is they'd throw them under that same bus -- and that's really what this comes down to. It's hard to be sympathetic with a company that gives up on its customers (paying or not) after "9 hours". Given that they had been hosted for 3 years prior, a night of DDoSing seems like a really isolated incident, and no reason to drop them permanently. Of course, we don't know if there were other DDoSes, but given that wrecked was so eager to share the piracy concerns and didn't mention any other DDoSes, I don't think there are any.

The issue isn't unplugging, I don't think anybody here thinks that it is unreasonable if they were to do this. The issue is that they kept the site unplugged for good because a single DDoS attack. My analysis based on the official response is that they used this incident as an excuse to drop the site because it was too much of a hassle to deal with the takedown notices.

> So assuming that pirate copy = a lost sale is a ridiculous argument.

This seems like a ridiculous counter-argument to me. You are basically trying to say that because a pirated copy is not exactly equal to one lost sale, then it's not an issue at all... forgetting the fact that the ratio doesn't need to be 1:1 for money to be lost. Let's assume, for the sake of argument, that "100 pirate copies = a lost sale", on average. That's still a lot of lost sales in the grand scheme of things, and that's a very conservative number.

As a sidenote, your anecdotal evidence is just that-- you got lucky having a friend with connections, most people without said friend would probably bite the bullet and make the purchase if they couldn't get it online. Let me inject my own anecdotal evidence for a second: before the internet, I remember renting a lot more movies than I do now. The internet has cut down on the amount of money I give to these organizations, fact.

And finally, whether or not Joe Blow got his money's worth is irrelevant, so who cares if you wanted your "free" back? The argument about value has little to do with the economic stance, unless you're trying to say, "it's ethical to steal if what you are stealing is crappy". I'd disagree with that statement too. I think most sane people would.

The unfortunate reality about writing your own new Bundler is that you'll inevitably end up rewriting Bundler. Isolate is basically just a mini-Bundler with a different (arguably simpler) storage location, but the storage location is really not where the complaints about Bundler are coming from.

Rewriting things just to shed complexity or "bloat" will often just put you in a position where your library just can't do things it will need to do, and then you end up rewriting those things and adding back the complexity. It's the circle of life. Lack of SCM support in Isolate is a good example-- I'm pretty confident that Bundler's support of git is heavily used and taken for granted, but if you were to rewrite or use a simpler dependency manager, you're throwing this out.

This point feeds back into the larger issue of Rails vs. Node, I think. Rails ended up with all the complexity it has now because it was [mostly] necessary-- not all of it was, but much of it was. The idea that you're somehow liberating yourself by shedding complexity is often just the short-sighted pleasure of running faster test suites. And it's usually followed by a little bit of claustrophobia when you realize you can't do X, Y, or Z anymore. Wait until the claustrophobia kicks in, because it will. And the solution to this claustrophobia? More cowb-- complexity.

Is autorequire even a real problem? You can quite easily put your gems in a separate group if you want to manually require them. Installing is another issue, that is opt-out, but I don't see the install process as the real bottleneck.

Yea, why hate on people who take advantage of and mislead uninformed newcomers to the Rails community by selling them existing free software that is trivial to set up, all the while passing it off as their own?

Maybe because some people believe in honest businesses, and not ripping off end users for a quick buck. I say mislead and rip of, because the site is presented as if the work done is novel, when it is not. Why is it that links to the libraries used are conveniently omitted? Shouldn't Bootstrap, Stripe, and KISSmetrics' codebases be linked somewhere so that users can see what it is they are getting, if they want to do it themselves?

That said, I think I will take you up on that replicating challenge. You are certainly right that someone should undercut the market before they make any undeserved money off the work of others.

The only thing wrong with C-11 as it stands currently are the digital lock provisions. Everything else in the bill is rather liberal, and, frankly, some of the provisions are outright good for Canadians (limits on fines, ISP liability exemptions, educational use exemptions, "mashup" exemptions). Calling for protests against the bill in its entirety is ignorant and blaming "the majority government" for passing draconian laws is outright sensationalist and false. That's not really how we do things here in Canada. There's a better way to get things done, and it doesn't involve hyperbole.

Yes, the digital locks portions of the bill could use some reworking-- but as mentioned, the enforceability of the law as its codified now is questionable, so I wonder how big of a deal it would actually be for the law to be passed as is. Remember, as pointed out, use of VCRs is also technically illegal, but you don't see any enforcement of that. The issue surrounding digital locks may very well have the same practical effect. We should certainly try to get these provisions changed before they are codified, but IMO it's not really the end of the world.

Yes, there is going to be a lot of push from powerful lobbyists to get "SOPA-like" provisions into the bill. However that is a reason to remain vigilant, not a reason to pre-emptively black out the internet again. As it stands, those additions have yet to be added to the bill, so right now, the lobbying power hasn't done very much. Maybe it's just me, but I'm not the type to start blaming people for things that haven't happened yet. I'm going to watch and wait until there is something reminiscent of SOPA in this bill, which may or may not happen.

FYI for those who are just jumping on the bus because SOPA is in the title of this article, please read a bit on the issue before injecting your opinion or outrage. Michael Geist is a good and well respected source on this issue. He's come out (more or less) in favour of the bill, minus his open objections to the digital locks portions, which I pointed out above. However, his general approval should say something about the bill-- Geist probably knows a lot more about copyright law in Canada than anyone here does. His comments regarding C-32 (now C-11) can be found in this rather old posting: http://www.michaelgeist.ca/content/view/5316/125/

There are two data sets, one from newrelic and one from gemstats.org. So, in short, no, it's not. It is, however, biased to the Rails community and web-apps in general, but this was mentioned. If you know a way to get a sampling of non-Rails usage, feel free to suggest.

First off, they are asking for your Gemfile, not your .gem. There is a big difference here. There is no source code in a Gemfile. Secondly, they clearly state why this is an indication of popularity-- they are getting real world usage statistics, not download counts. They ask for company info because if a company the size of 80 people uses a gem, it's going to effectively be more popular than a company of size 1. 79 more people are using it.

Please stop spreading the FUD.

Forked so that I can hopefully get one of those cool friendly emails!

Pre-processed here likely means what you think it means. DRY is not really a concept meant to be applied to method definitions (IMO), but rather method bodies-- of course there are many ways to abuse the interpretation of DRY as well. As far as whether you should care about compile vs load time-- in Ruby you don't need to, but if the language had static typing, it would make a difference.

Well, you're right about that distinction-- but from your comment "only on Tuesdays" I understood you were talking about behaviour modification some time after "load time". Also keep in mind the first paper cited in the article (profile-guided inference) actually points out that in most cases, "load time" can be inferred nearly statically-- as in, you would not need to run a test suite, you would only need to "load" the base code. This is a feasible task, in most cases.

Read the Starkiller dissertaion (for Python): http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90....

The compiler gives enormous optimizations for certain (admittedly extremely specialized) numerically intensive programs / calculations. Of course, if the compiler was developed further (it might be, actually), you'd probably see optimizations for larger sets of programs.

One of the points in the article is that this kind of behaviour modification is not done that often. Yea, it happens... but not as much as you'd think.

Depends which developers you're talking about. For the developers writing the code in question? Sure. For the developers trying to use that code? ...well, you're going to have to tell them about the types, or hope they can read your code-- the latter isn't really a win at all.

You don't "write a paragraph", you use a word. In fact, the point of patterns is to save you from writing a paragraph. Again, not to repeat the entire blog or anything, but that's why the words exist.

    # This is a singleton class
    class MyClass
      class << self
        private :new
        def instance; @instance ||= new end
      end
    end

Without looking at the methods or even the implementation I now know not to try to call `MyClass.new` because it's defined as a Singleton class. Simple. No paragraph necessary. You would need a paragraph if you didn't write this simple word.

And guess what? I just used the Singleton pattern.

"Maybe a better name for it would be "very global variable"."

The better name for it already exists: it is the Singleton pattern, because OOP software developers already understand this concept. You don't need to invent new names, this is why patterns exist. Also note that whether or not you use the "Singleton" mixin in Ruby, you are still using the Singleton pattern whenever you define a class with no constructor. Yes, you can do this without "include Singleton"; no, this does not mean you're magically using some new concept nobody's thought of before. You're still using Singletons.

* The blog post doesn't use any patterns at all. Given that there are no code examples or suggestions, I don't see how you came to this conclusion. The blog post never tells you how to use patterns, it tells you why you use patterns. Where does it advise you to "pick up components and use them to assemble complete programs"?

* Java did not exist when GoF wrote Design Patterns, so it clearly was not addressing any weaknesses of that language. Your point is DOA and you seem to be pulling this out of your ass. But, to elaborate: GoF isn't describing ways to patch any languages, it's describing ways to attack software problems. The idea of using a Strategy pattern (for instance) is universal among any programming language, it has absolutely nothing to do with code. So is using a factory method. Ever used `ActiveRecord.build` or 'create_with_...'? That's a factory method. The same concept applies with adapters, facades, et al. How you implement the pattern is completely irrelevant to the entire book. You could do it with dynamic dispatch or classes, the book doesn't define the patterns by their implementations. The point is you're using them. Pretending you're not is some kind of childish posturing so you can tell yourself you're "not doing anymore Java". I'm sorry you experienced your Java nightmares, but design patterns have nothing to do with that language.

I never claimed Active Record was a GoF pattern, in fact, I'm sure it would be easy to read that I cited "Martin Fowler". Whether or not it's GoF, Fowler or any other source doesn't change that it's a design pattern, though. GoF patterns are no different from Fowler's EAA patterns. One is not meant for static languages while the other is meant for dynamic. That's not how patterns work. If you think that GoF patterns were specifically made for Java, you should look at the publishing date of the book. You might also consider that the book uses Smalltalk in its examples. PS. Smalltalk is dynamic.

The problem with your argument is that the "triviality" of their implementation has nothing to do with whether or not you use them.

    class X < DelegateClass(String); end

This is using the delegate pattern. It's pretty damn trivial to implement. But we are using the delegate pattern. This is a fact. We can do the same for singletons, factories, facades, visitors and strategies. How you implement them does not define whether or not you use them. Whether or not you tell people you use them is what matters, because patterns are about communication, not implementation. If you don't understand this simple concept then you're completely missing the point of design patterns.

Yes, you can implement the Adapter pattern in Ruby without doing anything explicit-- that doesn't mean you didn't use the Adapter pattern. This is where denial kicks in. If you say "I don't use strategy patterns, I use DYNAMIC PROGRAMMING!" you're seriously deluding yourself.

"GoF patterns exist primarily to make up for the fact that you're not in Ruby"- this is the epitome of ignorance and the exact denial referred to in the article. I must have missed that part in Design Patterns that said "if you use Ruby you should not use this book".

But hey, I guess the Ruby stdlib includes the "Singleton" pattern for fun right? Not because you'd use it, or anything. Same with delegates. And I guess Rails didn't actually implement Martin Fowler's Active Record, Action Controller and MVC patterns? You just dreamed those.

Wake up. Your comment is painful and a little embarrassing. Design patterns are language independent. They are not implementation, they are descriptions. They can be used in any language, and they are used in Ruby.