Click the link below.
You are in Google street view. In front of you is an obelisk and a water tower.
Your task: get to the obelisk in street view (you are not allowed to go back to map).
Click the link below.
You are in Google street view. In front of you is an obelisk and a water tower.
Your task: get to the obelisk in street view (you are not allowed to go back to map).
@dhromed said:
@CPound said:
It's typical procedure to not discuss one's salary at work.An unwritten social rule; absolutely not factual procedure.
I've worked for a US company once where the standard contract explicitly listed disclosing your salary to co-workers as a fireable offense. Not that they checked on this or anybody was ever fired for it (and I doubt they would be able to hold it up in court), but it was factual procedure that is not uncommon in the US.
@dhromed said:
@JvdL said:@dhromed said:@CPound said:
It's typical procedure to not discuss one's salary at work.An unwritten social rule; absolutely not factual procedure.
I've worked for a US company once where the standard contract explicitly listed disclosing your salary to co-workers as a fireable offense. Not that they checked on this or anybody was ever fired for it (and I doubt they would be able to hold it up in court), but it was factual procedure that is not uncommon in the US.
I'd expect that some companies would have the twisted social insight of putting it in a contract, but that doesn't make it any more valid.
Other fireable offenses in explicitly listed in the standard employment contracts were: wearing flip-flops or mini-skirts, writing "What the fuck?" in corporate emails, drinking beer during work hours, smoking pot outside work hours, engaging in terrorist activities and so on.
@UNIX said:
Everything is a file
The UNIX and Linux crowd live by this dogma and apply it to the whole world.
Blakeyrat is a file called $home. If he doesn't want to be a file, he doesn't exist.
It's all Window's fault that it doesn't accept this dogma.
@asuffield said:
@JvdL said:Other fireable offenses in explicitly listed in the standard employment contracts were: wearing flip-flops or mini-skirts, writing "What the fuck?" in corporate emails, drinking beer during work hours, smoking pot outside work hours, engaging in terrorist activities and so on.
Even in the US, the courts have ruled several times that clauses which restrict what an employee does outside work hours are invalid. The best they can do is to write in a "morality clause", and that only applies to positions where the employee is explicitly acting as a role model or representative (eg, school teacher).
The clauses that restrict what you can say to other employees during work hours are treated as valid in most of the US, but you really do not want to work for anybody who uses them.
I'm not sure if that's true for illegal activities such as smoking pot or flying planes into buildings. Some US companies do random drug tests on employees.
Click the link below.
You are in Google street view. In front of you is an obelisk and a water tower.
Your task: get to the obelisk in street view (you are not allowed to go back to map).
@t_wheeler said:
Here's why I like checked exceptions. [...] Without checked exceptions, I'm going to end up with something like:
try { payrollSystem.printPaycheck(emp);
} catch(Exception e) {
// show a dialog box indicating things went wrong
}Why? Because I have no idea what exceptions are being thrown by printPaycheck() and no way to find out. But if I have checked exceptions I can do something more user-friendly:
try { payrollSystem.printPaycheck(emp);
} catch(DatabaseException e) {
// let the user know the database appears to be offline and they should try again later
} catch(NetworkException e) {
// let the user know there was an issue connecting to the network
} catch(PrintException) {
// let the user know there was a problem printing, maybe the printer is offline or needs paper?
}
And this has to do with checked exceptions.. what? You're confusing typed exceptions with checked exceptions. You can perfectly do typed catches in environments that don't support checked exceptions.
In addition, what you are doing here is wrong. You should not have caught those exceptions at all at that point if all you do is reporting errors. Reporting errors should only be done on the top level (entry point) and not at the code point that calls printPayCheck. At the top level, the system will know whether there is a user at all (instead of a deaf service call) and how to report (log? web page? message box?), That is something your coded point does not know. The top level also knows from the stack trace where the error occurred (print paycheck). One top level handler can handle all method invocations: printInvoice, shipOrder,...
@blakeyrat said:
@Renan said:I suggest using some good GUI, like Tower.I'd love to. Know of one for the platform 95% of the people on Earth use? (Github for Windows? Not good. Before you suggest that.)
Git Extensions is ugly as hell and somewhat clumsy but functional. No need to ever use a CLI. The error and warning messages remain Git's and therefore incomprehensible but the UI's visual cues are helpful enough that you can safely ignore Git core's babbling. Don't think you would have run into your troubles using this UI. Been using it for three years without ever reading any fucking manual and quite happy about it.
@Zecc said:
I don't think most people fully understand JavaScript's "var" (ie, the whole thing about variable hoisting), while Delphi's "with" keyword doesn't have much to understand (I think? I'm no Delphi expert, or even noob for that matter).It's just easier to abuse the latter than the former, that's all. You can't nest var declarations, unlike with statements and ternary operators.
Yes you can and this creates the same kind of scope soup as nested withs.
var x = function() { var x = function() { return x; }; return x; };
@Cassidy said:
@OhNoDevelopment said:So my suspicions are true! It's all meaningless (at least unit tests) and we should all live chaotically
Try a controlled test: one group do unit testing, another omit it completely. Compare the results.
@blakeyrat said:
Saying "it works but it's hard to use" is the same thing as saying "it doesn't work."
Saying "it's easy to use but it doesn't work" is also the same thing as saying "it doesn't work."
@boomzilla said:
@JvdL said:The supermarket accros the road sells beer for 0.38 euros per liter, which is about 1 labor-minute per pint of beer beating USA by seven laps.There's gotta be something funny going on there. Well, maybe that's the cheapest they sell? What kind of beer is it, anyways? That's roughly the price of generic (store brand) soda here. I also think you've inflated the median wage in Spain a bit. Definitely more than their calculation.
The brand is a blank store brand which I've never tried but makes you piss and gives you the same headache as any other beer.
The exact calculation is:
500 ml beer = 0.17 eurocents = 0.25 dollarcents. Median wage (according to The Economist / UBS()) = $3.05 per 15 minutes = $12.20 per hour = 9.50 euros/hr. That buys 48.75 pints of beer per hour = one pint every 1.2 minutes = 0.81 pints per minute
Any which way you round this, it falls in the one pint per minute range. Cheers.
() And then there's swiss banks.
@dhromed said:
@JvdL said:
Spain@JvdL said:The supermarket accros the road sells beer for 0.38 euros per literThat's just because your economy collapsed overnight. I bet you're considering switching to bottle caps for currency.
At least we're drunk, really.
There's lies, damn lies and statistics (*)
Spain's ranking of beer/minute is assuming a retail prices of $3.05 per pint to arrive at 15 labor-minutes per pint. The supermarket accros the road sells beer for 0.38 euros per liter, which is about 1 labor-minute per pint of beer beating USA by seven laps.
SPAIN!! SPAIN!! SPAIN!!
(*) And then there's swiss banks.@Salamander said:
@JvdL said:Logging to non-streams (email, SMS, event monitors) would be impossible.Whoever designed your logging framework is a moron anyway. You are not logging stream data; you are logging messages. Design a message handler interface and write a handler for streams, email, sms, whatever. Then, your logging framework doesn't have to give a shit about where it's sending data, just that its sending the correct priority message to the correct handler. Whether it is a stream or an email no longer makes any difference.
That moron is me and it is designed more or less the way you describe. To log, call
Logger.Warning("{0} is a moron because {1}", jvdl, designException);
The logger will handle such an invocation based on the severity (warning), the category derived by logger from CallingAssembly attributes and reflection. When sevcat merits logging, it compiles a message with time stamp, log text, user, source, machine, stack traces. It dispatches that to one or more handlers associated to that sevcat.
This has now been forbidden by the console police. According to them, every possible entry point needs to bootstrap the Logger with a std I/O reference wrapped in a TextWriter stream, regardless of whether the Logger will use it or not, or whether Logging is used at all. That's a fantastic design, especially for web apps that have thousands of entrypoints. Reminds of my Java days on Tomcat & Log4J. Fifteen years ago that was passable or maybe today when you get paid per line of code.Thanks but no thanks.