Recently somebody posted a forum message noting how easy it now is to compile under OSX [sourceforge.net]. I again posted this news, and asked if somebody could kindly compile it and send me a link to the resulting binary. Since then...nothing. Hence I have come to a conclusion about OSX users...well, I will let you guess what it is.
That most Mac OS X users already have the free iMovie that comes with their computer and never heard of your program because they don't have a need for it?
You probably have such an amazingly low amount of interested Mac OS X users that the magic combination of people with the proper knowledge, hardware, time, and caring doesn't add up to a single person. Dunno what happened to the guy who posted, maybe some day he'll come back.
It's not anti-capitlist. The companies will still be owned by capital investors expecting a return on their investment. Perhaps a few capitalists will have some of their potential gains transferred to the hands of other capitalists, but the class as a whole would suffer no net loss.
Truth be told, it is a bit anti-capitalist. Pure capitalism is completely unregulated trade, requiring that a company be split into two parts is regulating how the company can be run. That being said, I'm fine with it.
The problem with pure capitalism is that it really is a type of anarchy. Pure capitalism is no more desirable than pure communism, you need to have some structure and in order to restrict the wild swings and stale periods of a purely capitalistic environment. However, you don't want to over-regulate capitalism or you can kill the goose that laid the golden egg.
Of course, I didn't mean that those were examples of state. I was just giving examples of getters that might do more than simply return the value of a field.
I do agree that for a complicated function you definitely want to be verbose about what it's doing. The method name getRisk() implies that the method is simple, a name like calculateRisk() might be more appropriate for a more complex method - or even start going into names like calculateRiskByReferenceClassForecasting().;-)
Unless you're coding in Java, I definitely don't agree with the Java-style getRisk(), because the 'get' is redundant. Accessor methods usually take no arguments and return a value, so the fact that they 'get' something is obvious. Google's C++ style advocates risk(), as does Apple with Objective-C (the default accessors for properties even work this way).
I do a lot of programming in Objective-C and honestly I don't agree with Apple on this one. (Not that they need MY approval!)
Yes, the words "get" and "set" are a bit redundant but they are only 3 extra characters and they make scanning through code much easier. When you are reading code it is often helpful to easily see if a method is returning a value. I'd even argue that "set" is much less important than "get" because you can easily see that method takes an argument and is a setter, in fact most IDE autocomplete features fill the argument in for you. It's a lot harder to determine, just by glancing, if a method returns a value or performs an action so the prefix "get" provides valuable information.
setter:
investment.setRisk(number);// obvious, passes in number to risk
investment.risk(number);// still pretty obvious, passes in number to risk
getter:
something = investment.getRisk();// obvious, returns a value for risk
something = investment.risk();// not obvious - does this return a value or does it perform an action on the object and then return the object?
It's pretty bad in Objective-C too:
something = [investment getRisk];// the message "getRisk" is a getter and returns the value for that property
something = [investment risk];// is the message "risk" a getter or does it do some action and then return the receiver for message chaining?
Remember that another one of Apple's guidelines is to use fully-descriptive method names rather than ones that might be brief but not descriptive. Omitting the word "get" is a bit counter to that guideline and it's puzzling why they recommended it, especially when they have methods like: "initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:"
I don't think that 3 extra characters on an accessor is really gonna break the bank in light of stuff like that!;-)
Like I said in another post, none of this replaces reading documentation or understanding the classes you are working with. This is all about triggering your memory while scanning through code. Conventions like using "get" and "set" just allow you to more quickly and easily recognize what your code is doing, i.e. self-documenting code.
The proper design would have a unified method to calculate and return the risk. That method would check whether the Investment instance or anything else that affected the risk calculation had changed since the risk was last calculated. If so it would recalculate the risk, if not it should return the risk value that was previously calculated.
Well, of course!
Someone who looks at that code and wonders what Risk() does and whether it modifies an Investment instance or any static variables should be looking at the class documentation and/or the appropriate header file rather than guessing based upon what the calling code does.
I agree with this too. All I'm saying is that your code is so much more readable if you have a bit more than just risk(). It's certainly not a substitute for reading documentation and understanding the code, but a bit more verbose and carefully-chosen method name will jog your memory more easily and it stands out better than a terse method name. I'm not saying that calculateRisk() is the best name but it's a lot better than just risk(). I personally feel that getRisk() is even better and that's closer to what I'd use.
Investment.getRisk() looks too much like a getter method to me, so it might confuse others as well. I hate it when "getters" actually do meaningful calculation (outside just relaying state of the object) or worse, change state.
It is a getter. The thing is getters aren't just for simply echoing variables, they are also used to format encapsulated data from inside an object to hand off to the calling code. In this case the risk level is being gotten from the Investment object. It's a perfect use of a getter, even if the getter is doing the calculation on the fly. Risk might not be a stored value in the object but it is still an attribute of an Investment.
As for getters changing state, they shouldn't affect the object in such a way that is immediately obvious to an outside observer. However, they can do stuff like keep a running count of accesses, cache the results of calculations, and so on. Performing a HTTP request is definitely stretching it, I could see the argument for doing that but it'd be a tough sell.
risk() is also better. Since the author says its a method, it's in a class. Investment.risk() is a hell of a lot better than Investment.calculateRiskInvestment()
At a glance, does Investment.risk(): - return anything - change the state - perform validation
Yes, Investment.calculateRiskInvestment() is overkill and redundant but Investment.risk() is not clear enough. A good compromise is Investment.calculateRisk() or Investment.getRisk(). You know what action it is taking and what it is acting upon.
There is overkill in both directions, variables and method names that are too verbose and ones that say too little. The trick is finding a nice balance and, most importantly, having a very predictable and consistent naming convention.
I tend to write like that until I see a particular piece of code being used a second time, esp. from a different location. Then it is time to include it in a functions file...
As a self taught programmer/code monkey, is there anything wrong with that?
Yes, there is something wrong with that.
Technically I'm sure it all works but when you code code long stretches of code in one rambling function it becomes less focuses, difficult to read, harder to maintain, and you lose opportunities for code reuse.
First off: readability. Write a long, technically correct paragraph with a couple of dozen sentences. Now take that same paragraph and break it up into a couple of smaller paragraphs with 3 or 4 sentences each. Which is easier to read and follow? A long stretch of code has very few natural markers that allow you to parse what the code is doing. Remember that most humans can only hold so much in their short-term memory before they need to clean house. By breaking long stretches of code into smaller functions you provide context and limit the amount of information you need to keep active to understand the code. This means that the code is easier to understand, write, and maintain.
Another benefit is by having a couple of small functions verses one large one you make your code more modular. When your code blows up, and almost all code eventually does, it's much easier to refactor a small function than a large one. By using several small functions you limit the scope of the code you need to re-write, making the code much more easily maintained.
A great side-effect of small functions is that you start seeing many more opportunities for code reuse. Even if you have a large function without much repetition you might still actually have some nice sections of code that COULD be reused, if they were set apart from your large function. By breaking large functions down into small parts you help yourself to recognize those clever sections of code that would do well to be encapsulated in their own function and reused.
By encapsulating code into small, easily maintained, easily reused, functions that do a single thing well you greatly improve the quality of your code and make the job of programming much easier. Sure, what you are doing works for you and changing it might cramp your style for a bit but if you do make the change and stick with it you will become an even better programmer - especially when you work with others.
I don't understand why everybody is hung up on this fear of 'making mistakes'. Why is it every time that somebody suggests arming potential victims somebody else comes along and starts worrying about friendly fire? It rarely works out that way in the real world. It's even less likely in a maritime setting.
Oh, I totally agree. There is absolutely nothing wrong with mature, responsible people owning weapons with which to defend themselves. This is especially true in the case of being some 200 miles off the coast of Somalia, those ships should have deadly force in order to put up a good defense.
However, if you can disable a potentially hostile force and let the authorities deal with them then that's even better than getting involved in a firefight. It's safer for the defenders, it cuts down on the severity of mistakes, and it's much better legally and financially. I'd suggest a 2-tier strategy: first attempt to disable the attackers from a distance and then use deadly force if disabling them doesn't work/isn't possible. It's most likely to be the best of both worlds and the most sensible strategy.
In situations like this experience and good judgement are your best resources. Proper training and forethought will allow crews of cargo ships to pick the best strategy for handling potentially hostile forces. More options are almost always best in these cases.
You can't just disable boats on the open ocean and leave their crews at the mercy of the sea and elements.
Which is why you do it and then call the authorities to either capture or rescue the disable boats and their crew. If you really were in danger then you saved your lives and cargo, if you weren't then you pay the price of non-lethally attacking another boat. You still should do your best to make sure you really are disabling a pirate ship but if you do make a mistake it's a far less dire mistake than sinking the other boat and killing the crew.
If your timeframe is suitably large, a fine men's suit costs one ounce of gold, and a belt for it costs one once of silver, since Roman times. Compare against a fiat currency to get a rough measure of the effect of inflationary policy.
Which is why he said "The most you're going to get is a very rough estimation of what the dollar was worth."
It's a pretty typical problem, the less difference between the time periods/cultures/economies the easier it is to measure wealth. Once you have large differences your measurements become less accurate and you are reduced to more gross measurements like what you describe. This is fine for simple comparisons but it makes it much more difficult to accurately model the economic changes over time.
Nonsense. Every additional person is productive over his lifetime on the average. Plus, there is ever increasing capital wealth, multiplying productivity per person. My siblings and I are not on the farm (but we did work in my father's construction firm at one point). But if may parents' pension goes kablooey, there's enough of us producing enough so that they'll have no problems.
This is only true in the case of unlimited resources. Once you start to run out of land, oil, water, minerals, etc. then each additional person becomes an increasing liability. You can only be productive in relation to the amount of resources available to you. All realistic models of population growth show that adding additional members to make a population more effective only work up to a certain point, past that you experience diminishing returns and each new member becomes a liability. Yes, the death rate offsets this to some extent but only if it tracks the birth rate and keeps the population relatively stable.
Using multiple independent methods and combining their results is a good thing, because it avoids experimental error and potential systemic biases that exist in every observational setup.
This is definitely not a good thing.
Yes, it is good to validate one group of results gathered through one method by comparing them to another group of results gathered by another method. The problem is when you combine the two sets of data together. It is very easy to produce odd artifacts that way and it should be avoided at all costs. Differences in sample sizes, data collection methods, instrumentation, and other unknown and unintended introduced variables means that the combined data set is often much less accurate than the individual data sets.
The correct thing to do is to take each data set, analyze them separately, do your best to characterize the sources of error in each set of results and THEN compare the two sets. Then you can at least have a proper understanding of the strength and weaknesses of each data set with less hidden sources of error.
The problem with Keychain is that, by default, you don't actually need the master password to use the passwords it holds. It's deceptive, because if you use Keychain.app to access the passwords, you need to enter your master password. But if you use another application to access the Keychain, you don't need the master password.
Well, it's actually a little better than it seems. Not every application automatically gains access to every password. The application that you used to create the password automatically gets access to the password - after all if you used the application to enter a password then it follows that you trust the application with your password. If another application wants to use that password a dialog comes up which gives you information about the action and which asks you if you want the application to permanently have access to the password, just this once, or deny access. You can change these settings in Keychain Access.app
So the passwords are still pretty secure, if you trust the applications that use them. Of course if you don't trust the applications then it doesn't matter how you enter the password into them!
Hmm neat. I glanced at the site and it does look like a nice program, I'll have to keep it in mind. I wonder if there's a way to synch a Keychain database with a Keepass one. That would be a great compromise, Keychain when you are on Mac OS X and Keepass when Keychain isn't available.
I do wish that the iPhone could synch up with your computer's Keychain and allow you access with an iPhone app. It'd be a very handy way to always have your passwords available if you have an iPhone.
I use a mental hash for my less important passwords. That way all I have to do is look at the web site's name and run it through my hash function to come up with the password for that site. That way, I only have to remember the function and not the plethora of passwords.
It's a great idea and one that I've used in the past. What gets me are the PITA rules that some web sites use for passwords. Some want a certain amount of characters, some allow special characters others don't and even others REQUIRE them. My personal pet peeve: sites that force you to change passwords every so often and then don't let you re-use old ones.
I have a great idea: let ME determine if my password is secure enough. Don't try to force me to have a secure password, either I'm smart enough to come up with a reasonably secure password or I deserve to be hacked for not making one.
With all this it's tough to come up with a universal function to generate a password on the fly. You usually need 2 or 3 functions to adequately cover all situations and it's just too much work for me. I ended up using Mac OS X's built-in Keychain when I'm at my computer and a memorized prefix + a written down suffix for when I'm away from my computer.
Dunno why you'd need it on Mac OS X though, the built-in Keychain and Keychain Access.app does the same thing and more. It will do autofill, autofill after asking you for the master password, or you can just use it to store the passwords and look them up manually.
Keychain can also store secure notes and certificates for websites and such. It's pretty nifty how well it all works, you hardly ever have to worry about manually managing passwords and certificates.
Yeah... 17th century military tactics do leave a little to be desired... but they were more about the show than the actual killing, as muskets aren't exactly accurate weapons, or long range weapons, and battles were a spectator sport right up until the Boer war.
Erm, that's exactly the reason they would line up like that. If your troops have inaccurate smoothbore muskets then the best tactic is to line everyone up and you all fire in the same direction. With this line of fire it doesn't matter if the ball veers off target a bit, on average you will clear everything in front of you.
The British were amazing good at just this, in fact their lines were often several men deep so that the front men could drop to a knee and reload while the line behind them fired over their heads. Anyone facing the British in a straight-out battle were often massacred with these tactics. Many nations of this period used similar weapons and tactics.
Of course the Americans didn't use the same weaponry or tactics. They had newer rifles that had rifled grooves which shot more accurately and had a better range. They also would do ambush and retreat tactics (which relied on this accuracy), picking off the British bit by bit and attacking their supply lines rather than the main group of troops.
Of course when the Americans got caught out and forced into a straight fight they were usually steamrolled but eventually they were able to wear down the British. It helps that the British were fighting across an ocean and the Americans were fighting in their own backyards. Also, the Americans had a bit of assistance from France, Spain, and the Dutch Republic.
Basically times were changing and the British didn't change quickly enough. If the war had been fought just a little bit earlier the Americans wouldn't have had as many rifles and the British tactics would have been much more effective.
What you fail to understand is that the meme is not an argument or an accusation. It is a joke that you seemingly fail to get. It is called parody, and that is all it is.
Now, the fact that you take it seriously and feel the need to defend Glenn Beck against these "accusations" is hilarious. No one except an absolute idiot takes the parody site seriously or actually thinks Glenn Beck raped and murdered a young girl in 1990.
Oh, I get the "joke". It's not really much of a joke to begin with, it's really a commentary on Glenn Beck's style. I guess de gustibus on whether or not it's a good one.
I'm definitely not defending Glenn Beck, in fact I believe I condemned him for using those sort of arguments along with putting down the website as a rather poor commentary on Glen Beck's style.
But I guess you can paint me with that broad brush you're wielding because you think I don't "get it". Hey, it's a free country, go for it Mr. Anonymous Coward...
Absolutely. All death certificates now have a "Raped by Glenn Beck (Yes/No)" entry. Any entry marked "No" is taken to be a denial, which will be thoroughly investigated. Any entry marked "Yes" will be taken as evidence of guilt. Any invalid entry, such as illegible writing, invalid abbreviations, such as "N", entries left blank, or death certificates lacking this field will be interpreted as "Yes".
Aaaaaaaand there's always someone who kills a joke by going too far. Congrats!
You've somehow managed to completely miss the entire point of the domain in question. The entire meme about Glenn Beck raping and murdering a young women in 1990 was a joke created to parody Glenn Beck and his questioning of a Muslim guest on his show.
And you somehow managed to completely miss reading my entire post. Did you read this part of my post?
When you attempt to smear someone with guilt through association or by asking a suggestive question all you are doing is proving that you can't argue intelligently. This is doubly true when you claim you are doing it to give someone a taste of their own medicine. It's not a valid form of argument, either argue your case rationally or don't bother the rest of us with these antics.
If Glenn Beck did it then it's a weak argument. This website is also a very weak form of argument. I don't condone any use of this kind of fallacy, if you want to present facts then present facts, if you want to be a moral coward then your argument is useless to anyone.
But as near as I can tell, from reading the posts on this thread, he's one of those ultra-conservative blowhards who makes his living by indirectly accusing people of committing outrageous acts.
Actually, if you catch his show you'll see that he actually directly accuses people and even backs it up with evidence. I'm not a fan of his, he's a bit too confrontational for me, but whenever I do catch it he seems to have a pretty solid backing for what he is talking about. I'm sure that there's plenty of hyperbole involved, there always is with political pundits, but he certainly seems no worse than other such media personalities from all ends of the political spectrum.
That being said, the people who made this website are probably technically in the right but they are certainly morally in the wrong. When you attempt to smear someone with guilt through association or by asking a suggestive question all you are doing is proving that you can't argue intelligently. This is doubly true when you claim you are doing it to give someone a taste of their own medicine. It's not a valid form of argument, either argue your case rationally or don't bother the rest of us with these antics.
I happen to have my odometer and trip odometer set to the same digits because, well a trip odometer is useless
A trip odometer is far from useless. It is incredibly useful if you get a little creative. One great use is as a simple efficiency monitor. I reset my trip odometer every time I fill the tank, then when I go to fill it I note the miles used since last fill and the gas it took to fill the tank. A simple calculation gives you the approximate fuel economy, great for monitoring the state of your car. You can easily notice any gross problems such as a fouled plug or a bad fuel injector through the fuel economy. Of course, some cars give you the fuel economy on-the-fly but a lot don't.
Yes, you can do the same thing by difference on the normal odometer but that would require recording the old values and another calculation.
You can also use it to monitor stretches during a trip, matching up against a Google maps printout to see when a turn is coming up. Another good use is a rest indicator, reset it at the start of your trip and when it hits a certain value pull over and stretch, then reset it and go again.
The trip odometer is a convenience over the normal odometer. Use it often to save you bookkeeping and to provide you short-term information at a glance. It's certainly not going to make or break anything major but it can be a nice help.
Slashdot Mirror
Recently somebody posted a forum message noting how easy it now is to compile under OSX [sourceforge.net]. I again posted this news, and asked if somebody could kindly compile it and send me a link to the resulting binary. Since then...nothing. Hence I have come to a conclusion about OSX users...well, I will let you guess what it is.
That most Mac OS X users already have the free iMovie that comes with their computer and never heard of your program because they don't have a need for it?
You probably have such an amazingly low amount of interested Mac OS X users that the magic combination of people with the proper knowledge, hardware, time, and caring doesn't add up to a single person. Dunno what happened to the guy who posted, maybe some day he'll come back.
It's not anti-capitlist. The companies will still be owned by capital investors expecting a return on their investment. Perhaps a few capitalists will have some of their potential gains transferred to the hands of other capitalists, but the class as a whole would suffer no net loss.
Truth be told, it is a bit anti-capitalist. Pure capitalism is completely unregulated trade, requiring that a company be split into two parts is regulating how the company can be run. That being said, I'm fine with it.
The problem with pure capitalism is that it really is a type of anarchy. Pure capitalism is no more desirable than pure communism, you need to have some structure and in order to restrict the wild swings and stale periods of a purely capitalistic environment. However, you don't want to over-regulate capitalism or you can kill the goose that laid the golden egg.
Moderation in all things!
Of course, I didn't mean that those were examples of state. I was just giving examples of getters that might do more than simply return the value of a field.
I do agree that for a complicated function you definitely want to be verbose about what it's doing. The method name getRisk() implies that the method is simple, a name like calculateRisk() might be more appropriate for a more complex method - or even start going into names like calculateRiskByReferenceClassForecasting(). ;-)
Unless you're coding in Java, I definitely don't agree with the Java-style getRisk(), because the 'get' is redundant. Accessor methods usually take no arguments and return a value, so the fact that they 'get' something is obvious. Google's C++ style advocates risk(), as does Apple with Objective-C (the default accessors for properties even work this way).
I do a lot of programming in Objective-C and honestly I don't agree with Apple on this one. (Not that they need MY approval!)
Yes, the words "get" and "set" are a bit redundant but they are only 3 extra characters and they make scanning through code much easier. When you are reading code it is often helpful to easily see if a method is returning a value. I'd even argue that "set" is much less important than "get" because you can easily see that method takes an argument and is a setter, in fact most IDE autocomplete features fill the argument in for you. It's a lot harder to determine, just by glancing, if a method returns a value or performs an action so the prefix "get" provides valuable information.
setter: // obvious, passes in number to risk // still pretty obvious, passes in number to risk
investment.setRisk(number);
investment.risk(number);
getter: // obvious, returns a value for risk // not obvious - does this return a value or does it perform an action on the object and then return the object?
something = investment.getRisk();
something = investment.risk();
It's pretty bad in Objective-C too: // the message "getRisk" is a getter and returns the value for that property // is the message "risk" a getter or does it do some action and then return the receiver for message chaining?
something = [investment getRisk];
something = [investment risk];
Remember that another one of Apple's guidelines is to use fully-descriptive method names rather than ones that might be brief but not descriptive. Omitting the word "get" is a bit counter to that guideline and it's puzzling why they recommended it, especially when they have methods like: "initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:"
I don't think that 3 extra characters on an accessor is really gonna break the bank in light of stuff like that! ;-)
Like I said in another post, none of this replaces reading documentation or understanding the classes you are working with. This is all about triggering your memory while scanning through code. Conventions like using "get" and "set" just allow you to more quickly and easily recognize what your code is doing, i.e. self-documenting code.
The proper design would have a unified method to calculate and return the risk. That method would check whether the Investment instance or anything else that affected the risk calculation had changed since the risk was last calculated. If so it would recalculate the risk, if not it should return the risk value that was previously calculated.
Well, of course!
Someone who looks at that code and wonders what Risk() does and whether it modifies an Investment instance or any static variables should be looking at the class documentation and/or the appropriate header file rather than guessing based upon what the calling code does.
I agree with this too. All I'm saying is that your code is so much more readable if you have a bit more than just risk(). It's certainly not a substitute for reading documentation and understanding the code, but a bit more verbose and carefully-chosen method name will jog your memory more easily and it stands out better than a terse method name. I'm not saying that calculateRisk() is the best name but it's a lot better than just risk(). I personally feel that getRisk() is even better and that's closer to what I'd use.
Investment.getRisk() looks too much like a getter method to me, so it might confuse others as well. I hate it when "getters" actually do meaningful calculation (outside just relaying state of the object) or worse, change state.
It is a getter. The thing is getters aren't just for simply echoing variables, they are also used to format encapsulated data from inside an object to hand off to the calling code. In this case the risk level is being gotten from the Investment object. It's a perfect use of a getter, even if the getter is doing the calculation on the fly. Risk might not be a stored value in the object but it is still an attribute of an Investment.
As for getters changing state, they shouldn't affect the object in such a way that is immediately obvious to an outside observer. However, they can do stuff like keep a running count of accesses, cache the results of calculations, and so on. Performing a HTTP request is definitely stretching it, I could see the argument for doing that but it'd be a tough sell.
risk() is also better. Since the author says its a method, it's in a class. Investment.risk() is a hell of a lot better than Investment.calculateRiskInvestment()
At a glance, does Investment.risk():
- return anything
- change the state
- perform validation
Yes, Investment.calculateRiskInvestment() is overkill and redundant but Investment.risk() is not clear enough. A good compromise is Investment.calculateRisk() or Investment.getRisk(). You know what action it is taking and what it is acting upon.
There is overkill in both directions, variables and method names that are too verbose and ones that say too little. The trick is finding a nice balance and, most importantly, having a very predictable and consistent naming convention.
I tend to write like that until I see a particular piece of code being used a second time, esp. from a different location. Then it is time to include it in a functions file...
As a self taught programmer/code monkey, is there anything wrong with that?
Yes, there is something wrong with that.
Technically I'm sure it all works but when you code code long stretches of code in one rambling function it becomes less focuses, difficult to read, harder to maintain, and you lose opportunities for code reuse.
First off: readability. Write a long, technically correct paragraph with a couple of dozen sentences. Now take that same paragraph and break it up into a couple of smaller paragraphs with 3 or 4 sentences each. Which is easier to read and follow? A long stretch of code has very few natural markers that allow you to parse what the code is doing. Remember that most humans can only hold so much in their short-term memory before they need to clean house. By breaking long stretches of code into smaller functions you provide context and limit the amount of information you need to keep active to understand the code. This means that the code is easier to understand, write, and maintain.
Another benefit is by having a couple of small functions verses one large one you make your code more modular. When your code blows up, and almost all code eventually does, it's much easier to refactor a small function than a large one. By using several small functions you limit the scope of the code you need to re-write, making the code much more easily maintained.
A great side-effect of small functions is that you start seeing many more opportunities for code reuse. Even if you have a large function without much repetition you might still actually have some nice sections of code that COULD be reused, if they were set apart from your large function. By breaking large functions down into small parts you help yourself to recognize those clever sections of code that would do well to be encapsulated in their own function and reused.
By encapsulating code into small, easily maintained, easily reused, functions that do a single thing well you greatly improve the quality of your code and make the job of programming much easier. Sure, what you are doing works for you and changing it might cramp your style for a bit but if you do make the change and stick with it you will become an even better programmer - especially when you work with others.
I don't understand why everybody is hung up on this fear of 'making mistakes'. Why is it every time that somebody suggests arming potential victims somebody else comes along and starts worrying about friendly fire? It rarely works out that way in the real world. It's even less likely in a maritime setting.
Oh, I totally agree. There is absolutely nothing wrong with mature, responsible people owning weapons with which to defend themselves. This is especially true in the case of being some 200 miles off the coast of Somalia, those ships should have deadly force in order to put up a good defense.
However, if you can disable a potentially hostile force and let the authorities deal with them then that's even better than getting involved in a firefight. It's safer for the defenders, it cuts down on the severity of mistakes, and it's much better legally and financially. I'd suggest a 2-tier strategy: first attempt to disable the attackers from a distance and then use deadly force if disabling them doesn't work/isn't possible. It's most likely to be the best of both worlds and the most sensible strategy.
In situations like this experience and good judgement are your best resources. Proper training and forethought will allow crews of cargo ships to pick the best strategy for handling potentially hostile forces. More options are almost always best in these cases.
You can't just disable boats on the open ocean and leave their crews at the mercy of the sea and elements.
Which is why you do it and then call the authorities to either capture or rescue the disable boats and their crew. If you really were in danger then you saved your lives and cargo, if you weren't then you pay the price of non-lethally attacking another boat. You still should do your best to make sure you really are disabling a pirate ship but if you do make a mistake it's a far less dire mistake than sinking the other boat and killing the crew.
There are no Nobel Prize categories for astrology, professional wrestling, economics or phrenology.
Aren't those all covered by the Nobel Peace Prize?
If your timeframe is suitably large, a fine men's suit costs one ounce of gold, and a belt for it costs one once of silver, since Roman times. Compare against a fiat currency to get a rough measure of the effect of inflationary policy.
Which is why he said "The most you're going to get is a very rough estimation of what the dollar was worth."
It's a pretty typical problem, the less difference between the time periods/cultures/economies the easier it is to measure wealth. Once you have large differences your measurements become less accurate and you are reduced to more gross measurements like what you describe. This is fine for simple comparisons but it makes it much more difficult to accurately model the economic changes over time.
Nonsense. Every additional person is productive over his lifetime on the average. Plus, there is ever increasing capital wealth, multiplying productivity per person. My siblings and I are not on the farm (but we did work in my father's construction firm at one point). But if may parents' pension goes kablooey, there's enough of us producing enough so that they'll have no problems.
This is only true in the case of unlimited resources. Once you start to run out of land, oil, water, minerals, etc. then each additional person becomes an increasing liability. You can only be productive in relation to the amount of resources available to you. All realistic models of population growth show that adding additional members to make a population more effective only work up to a certain point, past that you experience diminishing returns and each new member becomes a liability. Yes, the death rate offsets this to some extent but only if it tracks the birth rate and keeps the population relatively stable.
Using multiple independent methods and combining their results is a good thing, because it avoids experimental error and potential systemic biases that exist in every observational setup.
This is definitely not a good thing.
Yes, it is good to validate one group of results gathered through one method by comparing them to another group of results gathered by another method. The problem is when you combine the two sets of data together. It is very easy to produce odd artifacts that way and it should be avoided at all costs. Differences in sample sizes, data collection methods, instrumentation, and other unknown and unintended introduced variables means that the combined data set is often much less accurate than the individual data sets.
The correct thing to do is to take each data set, analyze them separately, do your best to characterize the sources of error in each set of results and THEN compare the two sets. Then you can at least have a proper understanding of the strength and weaknesses of each data set with less hidden sources of error.
Yeah, everyone can cry fowl over Netscape being destroyed by Microsoft
DUCK!
The problem with Keychain is that, by default, you don't actually need the master password to use the passwords it holds. It's deceptive, because if you use Keychain.app to access the passwords, you need to enter your master password. But if you use another application to access the Keychain, you don't need the master password.
Well, it's actually a little better than it seems. Not every application automatically gains access to every password. The application that you used to create the password automatically gets access to the password - after all if you used the application to enter a password then it follows that you trust the application with your password. If another application wants to use that password a dialog comes up which gives you information about the action and which asks you if you want the application to permanently have access to the password, just this once, or deny access. You can change these settings in Keychain Access.app
So the passwords are still pretty secure, if you trust the applications that use them. Of course if you don't trust the applications then it doesn't matter how you enter the password into them!
Interestingly enough, Keychain is based on open source and open standards and Apple contributes to the project. It'd be pretty easy to integrate Keychain with other applications that follow the CDSA:
Common Data Security Architecture (CDSA)
Apple: Open Source - Security
Hmm neat. I glanced at the site and it does look like a nice program, I'll have to keep it in mind. I wonder if there's a way to synch a Keychain database with a Keepass one. That would be a great compromise, Keychain when you are on Mac OS X and Keepass when Keychain isn't available.
I do wish that the iPhone could synch up with your computer's Keychain and allow you access with an iPhone app. It'd be a very handy way to always have your passwords available if you have an iPhone.
I use a mental hash for my less important passwords. That way all I have to do is look at the web site's name and run it through my hash function to come up with the password for that site. That way, I only have to remember the function and not the plethora of passwords.
It's a great idea and one that I've used in the past. What gets me are the PITA rules that some web sites use for passwords. Some want a certain amount of characters, some allow special characters others don't and even others REQUIRE them. My personal pet peeve: sites that force you to change passwords every so often and then don't let you re-use old ones.
I have a great idea: let ME determine if my password is secure enough. Don't try to force me to have a secure password, either I'm smart enough to come up with a reasonably secure password or I deserve to be hacked for not making one.
With all this it's tough to come up with a universal function to generate a password on the fly. You usually need 2 or 3 functions to adequately cover all situations and it's just too much work for me. I ended up using Mac OS X's built-in Keychain when I'm at my computer and a memorized prefix + a written down suffix for when I'm away from my computer.
keepass is available for windows linux and osx
Dunno why you'd need it on Mac OS X though, the built-in Keychain and Keychain Access.app does the same thing and more. It will do autofill, autofill after asking you for the master password, or you can just use it to store the passwords and look them up manually.
Keychain can also store secure notes and certificates for websites and such. It's pretty nifty how well it all works, you hardly ever have to worry about manually managing passwords and certificates.
Yeah... 17th century military tactics do leave a little to be desired... but they were more about the show than the actual killing, as muskets aren't exactly accurate weapons, or long range weapons, and battles were a spectator sport right up until the Boer war.
Erm, that's exactly the reason they would line up like that. If your troops have inaccurate smoothbore muskets then the best tactic is to line everyone up and you all fire in the same direction. With this line of fire it doesn't matter if the ball veers off target a bit, on average you will clear everything in front of you.
The British were amazing good at just this, in fact their lines were often several men deep so that the front men could drop to a knee and reload while the line behind them fired over their heads. Anyone facing the British in a straight-out battle were often massacred with these tactics. Many nations of this period used similar weapons and tactics.
Of course the Americans didn't use the same weaponry or tactics. They had newer rifles that had rifled grooves which shot more accurately and had a better range. They also would do ambush and retreat tactics (which relied on this accuracy), picking off the British bit by bit and attacking their supply lines rather than the main group of troops.
Of course when the Americans got caught out and forced into a straight fight they were usually steamrolled but eventually they were able to wear down the British. It helps that the British were fighting across an ocean and the Americans were fighting in their own backyards. Also, the Americans had a bit of assistance from France, Spain, and the Dutch Republic.
Basically times were changing and the British didn't change quickly enough. If the war had been fought just a little bit earlier the Americans wouldn't have had as many rifles and the British tactics would have been much more effective.
What you fail to understand is that the meme is not an argument or an accusation. It is a joke that you seemingly fail to get. It is called parody, and that is all it is.
Now, the fact that you take it seriously and feel the need to defend Glenn Beck against these "accusations" is hilarious. No one except an absolute idiot takes the parody site seriously or actually thinks Glenn Beck raped and murdered a young girl in 1990.
Oh, I get the "joke". It's not really much of a joke to begin with, it's really a commentary on Glenn Beck's style. I guess de gustibus on whether or not it's a good one.
I'm definitely not defending Glenn Beck, in fact I believe I condemned him for using those sort of arguments along with putting down the website as a rather poor commentary on Glen Beck's style.
But I guess you can paint me with that broad brush you're wielding because you think I don't "get it". Hey, it's a free country, go for it Mr. Anonymous Coward...
Absolutely. All death certificates now have a "Raped by Glenn Beck (Yes/No)" entry. Any entry marked "No" is taken to be a denial, which will be thoroughly investigated. Any entry marked "Yes" will be taken as evidence of guilt. Any invalid entry, such as illegible writing, invalid abbreviations, such as "N", entries left blank, or death certificates lacking this field will be interpreted as "Yes".
Aaaaaaaand there's always someone who kills a joke by going too far. Congrats!
You've somehow managed to completely miss the entire point of the domain in question. The entire meme about Glenn Beck raping and murdering a young women in 1990 was a joke created to parody Glenn Beck and his questioning of a Muslim guest on his show.
And you somehow managed to completely miss reading my entire post. Did you read this part of my post?
When you attempt to smear someone with guilt through association or by asking a suggestive question all you are doing is proving that you can't argue intelligently. This is doubly true when you claim you are doing it to give someone a taste of their own medicine. It's not a valid form of argument, either argue your case rationally or don't bother the rest of us with these antics.
If Glenn Beck did it then it's a weak argument. This website is also a very weak form of argument. I don't condone any use of this kind of fallacy, if you want to present facts then present facts, if you want to be a moral coward then your argument is useless to anyone.
But as near as I can tell, from reading the posts on this thread, he's one of those ultra-conservative blowhards who makes his living by indirectly accusing people of committing outrageous acts.
Actually, if you catch his show you'll see that he actually directly accuses people and even backs it up with evidence. I'm not a fan of his, he's a bit too confrontational for me, but whenever I do catch it he seems to have a pretty solid backing for what he is talking about. I'm sure that there's plenty of hyperbole involved, there always is with political pundits, but he certainly seems no worse than other such media personalities from all ends of the political spectrum.
That being said, the people who made this website are probably technically in the right but they are certainly morally in the wrong. When you attempt to smear someone with guilt through association or by asking a suggestive question all you are doing is proving that you can't argue intelligently. This is doubly true when you claim you are doing it to give someone a taste of their own medicine. It's not a valid form of argument, either argue your case rationally or don't bother the rest of us with these antics.
I happen to have my odometer and trip odometer set to the same digits because, well a trip odometer is useless
A trip odometer is far from useless. It is incredibly useful if you get a little creative. One great use is as a simple efficiency monitor. I reset my trip odometer every time I fill the tank, then when I go to fill it I note the miles used since last fill and the gas it took to fill the tank. A simple calculation gives you the approximate fuel economy, great for monitoring the state of your car. You can easily notice any gross problems such as a fouled plug or a bad fuel injector through the fuel economy. Of course, some cars give you the fuel economy on-the-fly but a lot don't.
Yes, you can do the same thing by difference on the normal odometer but that would require recording the old values and another calculation.
You can also use it to monitor stretches during a trip, matching up against a Google maps printout to see when a turn is coming up. Another good use is a rest indicator, reset it at the start of your trip and when it hits a certain value pull over and stretch, then reset it and go again.
The trip odometer is a convenience over the normal odometer. Use it often to save you bookkeeping and to provide you short-term information at a glance. It's certainly not going to make or break anything major but it can be a nice help.