Show Us Your Production Code(say26.com)
say26.com
Show Us Your Production Code
http://say26.com/show-us-your-production-code
11 comments
Not everyone has the luxury of owning the IP to their production codebase. If you want to start posting chunks of it online you're going to need a better excuse to give your boss than "I want to win an internet argument".
It's not to win an argument but rather to share it with other developers (and get feedback). So your request to the boss will sound like "I'm hesitant if this piece of code is the best way to do it, can I show it to the world?"
Well, saying that might sound like you are suggesting you don't know what you are doing. Besides it's unlikely that you are going to get meaningful feedback based on one chunk of code without the context of all the other stuff it interacts with.
If that level of peer review is really important to you , then you would be best off releasing the source to your entire app.
If that level of peer review is really important to you , then you would be best off releasing the source to your entire app.
Have you been following all the Ruby discussions in the past few days? A single action from a complex controller in Basecamp would be enough for me to understand how 37 Signals are handling the not so skinny controller stuff.
It would be much more useful than seeing another 'create user and send email' stuff, which I see in almost every article about controllers.
It would be much more useful than seeing another 'create user and send email' stuff, which I see in almost every article about controllers.
Not really, but I don't think seeing a bunch of code with calls to hidden function would be all that useful.
It is simple enough to distill your approach down into some fictional code that can be easily understood. I do it all the time when I'm posting questions on Stack Overflow and don't want to stick the real code on there.
It might be nice to see some of their production code, but it doesn't really offer any value to them other than being able to fire a shot in an internet war.
It is simple enough to distill your approach down into some fictional code that can be easily understood. I do it all the time when I'm posting questions on Stack Overflow and don't want to stick the real code on there.
It might be nice to see some of their production code, but it doesn't really offer any value to them other than being able to fire a shot in an internet war.
Are you not concern about many security issue with showing production code?
Showing one controller action or model method will not compromise your application security.
I'm not saying people should put their application to github, just asking them to use real examples in their articles (like I did with MessagesController#create)
I'm not saying people should put their application to github, just asking them to use real examples in their articles (like I did with MessagesController#create)
In security circles Kerckhoff's principle is usually accepted. (https://en.wikipedia.org/wiki/Kerckhoffss_principle) It essentially says, that security by obscurity is a bad idea.
I wouldn't be. Some of the most secure software in the world is fully open source. Having millions of eyeballs looking and touching your code is a lot more secure than having 5 ego-driven devs who think they know security.
Perhaps the reason is that the actual production code is an unholy mess that they'd be ashamed to show?
Many times during my career, I've had to deal with those who profess to know the "right way" of doing things. They'll throw acronyms like DRY and YAGNI at you all day. They'll go on and on about patterns and "best practices". Yet when it comes to writing actual production-grade code, they often produce the worst of the worst.
This behavior has, in my experience, been extremely prevalent within the Ruby community, and with the JavaScript community to a lesser extent. So I wouldn't be at all surprised to see them making all sorts of recommendations, without ever backing it up with real-world code.
Many times during my career, I've had to deal with those who profess to know the "right way" of doing things. They'll throw acronyms like DRY and YAGNI at you all day. They'll go on and on about patterns and "best practices". Yet when it comes to writing actual production-grade code, they often produce the worst of the worst.
This behavior has, in my experience, been extremely prevalent within the Ruby community, and with the JavaScript community to a lesser extent. So I wouldn't be at all surprised to see them making all sorts of recommendations, without ever backing it up with real-world code.
That's been my guess as well. Probably some developers are ashamed. But if you think about it, sharing real, messy code is much more useful than showing a polished, contrived example.