|
I am right there with you... brute force the answer.
Now if the puzzle had specified a minimum number of symbols to achieve 1000, or that you only have 100 8's and 99 +', etc. You would have to go with the first reply.
|
|
|
|
|
That's perfectly good solution... Not nice, but good...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I'll have a P, please, Bob.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
So I'm looking at NLog and Log4net. Why in the world does logging need to be so blasted complicated???
Now I'm sure some of you would say "Log4Net or NLog isn't complicated", but at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }
static Logger()
{
if (string.IsNullOrEmpty(LogFile))
{
var path = System.Reflection.Assembly.GetEntryAssembly().Location;
LogFile = string.Format("{0}\MyLogFile.txt", path);
}
}
public static void Info(string message)
{
using (var sr = new StreamWriter(LogFile, true))
{
sr.WriteLine(message);
}
}
}
I've never understood why This Much is needed just to write to a silly log file. Seems to me that these "tools" are just a solution looking for a problem.
IMHO, WAY WAY WAY over-engineered.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
No, haven't seen it. I'm just venting on why it's so blasted much work just to write to a log file.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Logging frameworks (etc.) are for developers who are too stupid to figure it out for themselves.
If you're smart enough to recognize that the framework is crap, you don't need that framework.
|
|
|
|
|
I disagree. When you have code running in production it;s usually more difficult to diagnose what's happening, so logging gives you an advantage.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Me thinks you misunderstood. By "the framework" he's referencing "the Logging framework", not logging in general.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
Are you seriously suggesting re-inventing the wheel?
"There are only 10 types of people in the world - those who know binary and those who don't."
|
|
|
|
|
Same old argument. If the existing wheels don't fit your needs you create the right wheels. A developer who doesn't do as much isn't worth a dime - baceause creating tools is precisely programmers' work.
CALL APOGEE, SAY AARDWOLF
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
"Go ahead, make my day"
|
|
|
|
|
Totally agree. Nothing wrong with using 3rd party code or frameworks but no one shoudl be afraid to roll up their sleeves and make it themselves if the need fits.
|
|
|
|
|
Meh. I'm getting paid for solving problems using software. Logging is a problem that's been solved numerous times already, and there's a multitude of amazing frameworks to choose from. Spend a few minutes reading (and understanding) the documentation, instead of wasting time trying to write another one from scratch. Not only will you end up with a better solution, it will be cheaper as well.
|
|
|
|
|
For a simple application, what you posted may suffice. For complex, multi threaded services, the logging needs to be thread-safe, needs to be performant (even async), and may need to support multiple log listeners - and the target may be a text file, a database, azure storage, a web API, etc.
That said, some of these logging frameworks kept adding features and now are unnecessarily complex, and may have reached a saturation point of over-engineering.
|
|
|
|
|
Nish Nishant wrote: That said, some of these logging frameworks kept adding features and now are unnecessarily complex, and may have reached a saturation point of over-engineering. Adobe is doing the same thing with Photoshop now. I hope it doesn't get worse, that's been one of my favorite apps for so many years. If it goes to crap it'll be a sad, sad day for computerland.
Jeremy Falcon
|
|
|
|
|
I don't have it yet but the personal use subscription is quite affordable. 10 bucks a month gives you Photoshop and a couple other tools I think. You never really own it though - just a lease.
|
|
|
|
|
Yeah totally, and they allow you to use it on more than one computer, so it's not too shabby. But when you start using the new version (CC 2017) it just starts to seem like the new crap is just too much and is distracting. And I've always used Photoshop as an example of a simple, clean yet powerful UI design. Not so much now.
Jeremy Falcon
|
|
|
|
|
I still use PhotoShop 7 (2002) -- it has never suddenly changed how it works. Nor has Office 2003.
|
|
|
|
|
Oh snap.
Jeremy Falcon
|
|
|
|
|
I recently came across instructions showing one how to legally download Photoshop CS2 along with it's key
I don't currently need anything more advanced than that.
The short version is to create an account on the Adobe site, search for CS2 and download with key...
|
|
|
|
|
7 has always done what I need.
Now that I'm getting back into photography I might look for something newer.
|
|
|
|
|
X = What features you need from your logging system
Y = What features a logging framework provides
Usefulness of logging system = 1 / (Y - X)
|
|
|
|
|
Clearly some stuff is over-engineered. If what you've posted meets your requirements, then by all means--you shouldn't ever feel obligated to use any of the bloated alternatives that exist.
|
|
|
|
|
Kevin Marois wrote: at the most basicl level, what's wrong with this:
public class Logger
{
public static string LogFile { get; set; }
static Logger()
{
if (string.IsNullOrEmpty(LogFile))
{
var path = System.Reflection.Assembly.GetEntryAssembly().Location;
LogFile = string.Format("{0}\MyLogFile.txt", path);
}
}
Well, it won't work in production for starters!
The Executing assembly in production is normally in a folder that "hangs off" "Program Files" or "Program Files (x86)", and folders in that path are normally write protected for antivirus reasons.
Use a "publically writable" folder like one below Application.CommonAppDataPath or Environment.SpecialFolder.CommonApplicationData :
public static Guid AppGuid
{
get
{
Assembly asm = Assembly.GetEntryAssembly();
object[] attr = (asm.GetCustomAttributes(typeof(GuidAttribute), true));
return new Guid((attr[0] as GuidAttribute).Value);
}
}
public static Guid AssemblyGuid
{
get
{
Assembly asm = Assembly.GetExecutingAssembly();
object[] attr = (asm.GetCustomAttributes(typeof(GuidAttribute), true));
return new Guid((attr[0] as GuidAttribute).Value);
}
}
public static string AllUsersDataFolder
{
get
{
Guid appGuid = AppGuid;
string folderBase = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData);
string dir = string.Format(@"{0}\{1}\", folderBase, appGuid.ToString("B").ToUpper());
return CheckDir(dir);
}
}
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|