OpenUserJS
Decide which of the current `console` messages are to be production/development/debug environment
Currently we have a bunch of console.log, console.warn and console.err lines in our code... decisions need to be made on which is to be applied to the isPro, isDev and isDbg flag tests.
Also needed are some more console messages to actually point out the flow of our MVC. Please discuss this here.
Just leave them all.
All of the above is an option... however since you aren't reading the deployment logs this may not be an option.
This is pretty much a non-issue.
Perhaps from a narrow minded perspective but you might want to consider someone else besides just you.
@Martii commented on 20 nov. 2014 06:43 CET:
Perhaps from a narrow minded perspective but you might want to consider someone else besides just you.
There's no one else to discuss this with, apparently you are the only one with access to 'these so called logs'.
No sizzle is the one with that access from what I can tell and I don't know exactly where he dug one up he sent me... there's also hosting support that definitely has the logs... so yes it is more than just one person.
Everyone is also forgetting dev/dbg is one user maybe two... whereas production could be hundreds or more... so selectively choosing what shows and what doesn't when and where is a good thing.
Any logging in master is production logging. If you have dev/debug logging, it should be removed or commented out before being merged.
I agree that there should be more logging during user initiated events, but it's not terribly necessary unless it's required to debug something in production and/or to count how many times an event happens. Basically, if you notice something should be logged when you're refactoring, insert some logging in it when you make your PR.
Likewise, if you notice something is spamming, make a PR to remove/comment it out. There isn't really a need to discuss this problem in general since every use case is different.
@Zren It is painfully obvious that you don't have an understanding of what is going on as of late and have been fighting the project for some time now. It's great to share your opinion however your limited ability to see the larger picture is proving to be a hindrance.
Production has debugging whether you like it or not... your misconception of this process really needs to lay low for a while... and to quote someone else you are completely and absolutely incorrect on your interpretation of this. Even if you bring up all the bad examples from node projects to "prove" your point there is absolutely no beneficial reasoning behind limiting production with an arcane and immature decision by stripping debugging. I have already proven that production has issues that can't be resolved in development nor debug mode... so have you but you choose to ignore the facts.
Anyhow... I'll be working on this in the next few days... with any luck.
apparently you are the only one with access to 'these so called logs'.
Which makes it difficult to know for those only used to logging output in dev environments.
no beneficial reasoning behind limiting production with an arcane and immature decision by stripping debugging
I was talking about removing "the code has reached enteredMethodA()" to debug broken logic errors when code is being written, after the code is considered bug free and before a PR is made. I did not mean we should remove logging required to find bugs in production.
- Anything logged in production does not need an
isProcheck as you should be logging it in development as well. - Anything logged in development does not need an
isDevcheck as if it's not making it intomasteraka production then you can just use basicconsole.log()statements which you can delete (or comment out if they're rather useful) before commiting them.
Which makes it difficult to know for those only used to logging output in dev environments.
I would like you to go read my "fluff", as you put it a while back, for jitsu. This has been referenced on the main page for a bit with the README.md... in particular read this section.
I've also shared with you #425 which is part of the host... nodejitsu isn't your traditional virtual nix host... it has its own front end and it's own back end.
I've also shared that the pro has an environment that is displayed like a JSON file... e.g. we can set the configuration... so please don't act like you don't know what's going on... you have been shared with.
You are one of the smartest/quickest coders I've seen but you are also the least focused that I've seen in a while... don't let me down by missing the points... ask a question if you need one from me and I'll do the best that I can to answer it.