I agree that I don't like trees, but in HN just go to your user in the upper-right, and click on comments. Problem solved! Still a tree, but no more clutter.
Looking at flat comments for an involved discussion is sometimes confusing because you have to scroll around even more to see who is replying to what.
Maybe PG would provide an option in user config to view comments in a list rather than a tree if we asked.
* There is a reason for autoloading: faster development. Even though you should not usually need to make app-specific configuration changes outside of the main environment.rb and each environment-specific config (development.rb, etc.), if you do, you might consider putting them into a module in an autoload path, and make sure that the fully-qualified path (A::B::C maps to something like app/models/a/b/c.rb) is correct, so that it autoloads without trouble.
* Some suggest putting constants for frequently used values in a file somewhere under config/initializers. That way Rails doesn't complain when reloading them. But, that doesn't autoload if you make changes in development.
* You can extend a Module that is autoloaded with methods that are "marked" with module_function :method_name to become private class methods on the class that extends them. This way you have non-inheriting methods that basically act like config variables.
* You can just use class_attribute in Rails to define inheritable attributes and then use self.the_class_attr_name = something to set them in the body of the class for configuration.
* attr_accessor :some_var_name, @@some_class_var, @some_instance_var, a hash, a Struct, or a OpenStruct are fine ways to hold config values and can be set inline for class vars, in the initialize method for instance vars, or methods called by other hooks, depending on what you need.
* Usually avoid $some_global_var as there is no way to tell whether it has been defined nor whether it has been set explicitly to nil.
author of rails_config here. rails_config is sort of nice because you can use ERB so mix your regular settings along with ENV settings
That said, it's not been a terribly well maintained project. Haven't had time, needs help! I still use 0.2.5 since that's the only one that works for me :)
I have been on Twitter since the beginning but I have no idea why people use it. The length restriction is totally lame, UX is rough, and it seems infested with wannabe's (followers), selfish people that live to share their lives with hashtags and pics of innane shit, Ashton, self-proclaimed "social media experts"), and hookers. Facebook has old people, and I'm one of 'em.
To me, Twitter seems more compatible with the older internet user's view that what you do on the internet should, if you want it to be, be somewhat anonymous. Or at least feel that way.
There is only one semi-reliable auth method: deep body scan + DNA + mitochondrial RNA + retina scan fuzzy match. Passwords and 2 factor auth suck. And so will embedded/mark IDs, which I will never, ever use.
This is a good idea- everyone worth their salt wants a third-party single auth service, perhaps one that we pay an annual fee for, however this ain't it yet. You should not piggyback. Don't.
Notch, I'm so sorry. I know what it is like to lose a parent. It sucks and it doesn't seem to go away.
What a great post. Thanks for sharing your life with us. Please continue to make your dad proud, and be a path for the rest of us in similar circumstance.
This is a good guess. Disney just bought LucasArts, and they pulled a similar stunt for Tron Legacy: they setup a website flynnlives.com and provided hints to a location in San Diego where they had recreated a Flynn's arcade that people had to find.
However, considering the last Indiana Jones film was a miserable flop (spoiler ahead: was it the hiding in the refrigerator or the UFO that nailed that coffin), they would have to fully recreate the old Harrison Ford in CGI PERFECTLY with a great plot to get me interested, and btw Disney I expect the same for the new star wars final trilogy or the remake of the first three after removing all of the Jar Jar sequences and replacing the obi wan with a younger CGI version of Alec Guiness and getting rid of the lame Jabba, etc. bad CGI crap they added to New Hope, etc. People should learn a lesson from LucasArts; when you have customers for life, continue to cater to them as they age. Also what about some Biggs Darklighter in a new series? For the kids, how about an Ewok that learns to kick ass in a tie fighter?
Long methods are not as easily testable, but overly short methods can make code much harder to read and follow and actually increase complexity, because now there are many more entry points, leading to excessive nil checking, etc. for those practicing paranoid TDD.
Even the developers of Rails are not sold on the promise of the null object pattern, and as it states as almost an afterthought that "it can lead to confusion" (paraphrased). If you are a developer, especially one that is a refugee from a more "type-safe" language, you are more likely to assume that:
an_object.a_method
Will fail if an_object is nil/null. By making an_object a null object, then you can end up with is_a?(NullSomething) when other programmers are using your API, defeating the whole purpose of trying to avoid additional try's and other checks in the code. It can be a bad code smell to use null object pattern in many situations.
Case statements can be a bad code smell, just as is_a?(...), but not in every situation. Often they can be a clear and concise way to get the job done. In Java the switch statement was ridiculed, only to produce a whole generation of Java developers that either had chained if's or would create 3x the code just to introduce a pattern for simple logic!
So, if the rest of this book is like this, please take it with a grain of salt. It is a reference for another way of thinking about things, but if you are going to do that, read "Design Patterns" by the GoF and "Refactoring" by Martin Fowler also. And then forget all of that and try to write DRY Ruby code in as few lines as possible without tests to get a feel for that. Then give both up and seek a middle ground. In this way, you will be like Bhudda. Neither conservative "tests, patterns, and refactoring is the only way or you are shunned" nor liberal "it doesn't matter how you write it, just write what you like" are the ways to enlightenment; it is the way between them.
Agreed on method extraction; overuse will just introduce more hoops to jump through when trying to understand the code. Unless you're moving methods to other classes, though, you can avoid adding entry points to the API by extracting methods as private. We use private methods to reveal intent, break down large methods, and reuse behavior within a class.
Also agreed on Null Object. I tried to make it pretty clear in the chapter that it's not a one-size-fits-all kind of solution and must be used with care. I strongly advise against using is_a?, ===, or case statements to check for null objects.
You can define present? to be false on your null class if you NEED to check for a null object, but the pattern is only useful when the higher level code (views, etc) don't need to care about whether or not the object is null. If you have to add present? checks to everything, I'd advise against using null objects.
The book is also trying to highlight that "middle way" you're talking about. Each chapter tries to outline the benefits and drawbacks of using a particular approach. We've stressed that you don't need to "fix" every code smell you find, and that the solution depends on the specifics of an application. The book is designed to give developers a better understanding of the methods for finding and fixing problems, and the solution chapters try to give the developer the ability to decide what the best solution is for a specific situation, rather than trying to achieve an "if x then you always y" kind of approach which doesn't work in the real world.
> Overly short methods can make code much harder to read and follow and actually increase complexity, because now there are many more entry points.
Ideally there wouldn't be any more entry points. If we create multiple short well-named private methods they should make it easier to follow your code. Side benefit of well-named methods is they can act as simple documentation for readers.
> Case statements can be a bad code smell, just as is_a?(...), but not in every situation.
More often than not when doing a code review a case statement will catch my eye. Often they are OK, but more often than not they can be avoided.
> Read "Design Patterns" by the GoF and "Refactoring" by Martin Fowler also.
So important to read these. They are great for all developers. The idea behind Ruby Science is to show how to use these techniques in a Ruby on Rails application. With real code, and real refactoring (along with code, and a history of git Commits to show the exact changes we're making).
