Live data from Hacker News

Things to commit just before leaving your job

gist.github.com

121–130 of 165 posts

Re: Things to commit just before leaving your job

#121
post #40
post #6

Earlier quoted context omitted.

Got a offshore guy just like that. Constantly committing his whole project where most files are out of date and only the few he worked on are not. There's no reason for him to commit javascript files he doesn't even work on the front end. It took me forever to figure out he wrote over my files the other day.

He must be using push --force in that case.. which seems like a bad practise.

What they're doing is something like branching off a very old version of master, making changes to file A then trying to merge into the latest version of master, which already has a load of changes to file A. They then resolve the conflict by picking "ours", thus ignoring all changes on origin/master in favour of their own old version of master. This doesn't require a --force.

Re: Things to commit just before leaving your job

#122
Wouldn't it be wise if the compiler (or preprocessor) issued at least a warning if you redefine language keywords ? :)

So I just pasted this into a C++ file I was working on and it compiled without a single warning:

#define struct union

#define if while

#define else

#define break

#define double float

#define volatile // this one is cool

I mean, redefining language keywords is not a thing I do every day and I guess most of you don't do it either and I can't see a valid reason why you'd want to do it in a normal project. For people who really want to do it, they'd just disable the warning.

Am I missing something here ?

Re: Things to commit just before leaving your job

#123

Earlier quoted context omitted.

and everyone else. Seriously. No sympathetic human being would do this without a deep-rooted hatred to everyone involved.

my theory is that in every case where this has ever happened, all of the saboteur's ex-coworkers afterward said "I'm not surprised in the slightest."

Or they talk about her like the neighbors of a mass murderer. "She was a quiet woman, always kept to herself."

Re: Things to commit just before leaving your job

#124

Earlier quoted context omitted.

The point wasn't to leave people puzzling over it for hours. It was a bit of fun. But ... It'd be quite trivial to hide the string. var msg = ['E','r','r','o','r',':','S','c','r','i','p','t',' ','n','o','t',' ','f','o','u','n','d']; document.write(msg.join(''));

Base64 encode the string for added fun.

... and then caesar-cipher it so that the first guess won't easily find it? :D

Re: Things to commit just before leaving your job

#125
post #38

It is always a funny joke to say "commit this when you leave a job". But I always wondered if there are people that actually do this. Although it could be funny and give a sense of revenge for some wrong (perceived or real) that the person leaving might have suffered, I don't think this would be a good idea. Contracts usually include liability for gross negligence or wilful misconduct. Does anybody have a record of t…

Worse. Depending on the jurisdiction, they may be able to get you arrested for hacking.

Or vandalism.

Re: Things to commit just before leaving your job

#126

I joked about starting a salary spreadsheet during my last week. Management wouldn't even make eye contact with me on the last day. :P

I don't get this one. Could you elaborate?

I think everyone knowing everyone else's salary would cause major problems, at least here in the US. It would be a major source of headache for management as they try to triage complaints from employees who are getting paid less than their colleagues with the same title or similar experience (or even less experience).

Re: Things to commit just before leaving your job

#127

The horror story that I heard was a disgruntled engineer silently replaced the source codes (C++ based) in the project with compiled binary object files and he kept the source codes on his local computer, not checking those in. He did this over an extended period of time to make sure this crept into the backup tapes as well. No one found out because each engineer owned a code module of their own. Then he resigned. Wh…

what happened as a result? im curious to know.

Re: Things to commit just before leaving your job

#128
post #99

Earlier quoted context omitted.

PHP actually allows much less mischief here than C or, say, Python does. It doesn't let you redefine or delete functions, classes or constants, unlike C where macros can be abused for this, and Python where you can delete anything. But you could hide all errors if you want to screw with people: error_reporting(0); set_ini('display_errors', '0'); set_error_handler(function () { return TRUE; }, E_ALL | E_STRICT); set_e…

Well yes of course you can, we're talking about PHP here. http://php.net/runkit_function_rename

runkit isn't in stock PHP.

A thing you have to understand about PHP - at least, the php.net/Zend Engine PHP most people use - is that what is and isn't in its "standard library" isn't as well-defined as it is for, say, Python. At its most basic, PHP is just the /Zend directory of the source tree: a lexer, parser, compiler and interpreter for PHP code. It can run PHP code, but Zend alone can't do anything except maybe tell you how long a string is.

In order to actually do anything, you need functions and classes that interact with the outside world. And all of these, even the "standard" ones, are implemented as extensions. These are libraries that plug into the Zend engine and expose functions, classes and constants. You can enable them or disable them at compile-time. You can build them into the interpreter itself (static linking), or load them at runtime (dynamic linking).

PHP's source code repository, alongside the /Zend directory containing the PHP interpreter, also contains an /ext directory containing a bunch of different, useful extensions. Only a few of these are always compiled and cannot be disabled, such as /ext/standard, which includes a large number of functions dealing with things like file I/O, strings, array manipulation, password hashing, number conversion, and so on. There's also /ext/date, which manipulates dates. These are the only extensions guaranteed to be available in PHP. They're the most minimal definition of PHP's standard library.

But there's a lot of other stuff in /ext. There's JSON parsing (/ext/json), database connectivity (/ext/pdo, /ext/mysql, etc.), image drawing (/ext/gd) and arbitrary-precision arithmetic (/ext/gmp) among other things. These are all maintained by the core PHP maintainers alongside PHP versions.

However, alongside all of these, there's tons of community-maintained extensions in PECL. You can find all kinds of stuff in there, such as runkit, the extension you're talking about. Sometimes, extensions from PHP core move into PECL (usually dead ones), sometimes extensions from PECL move into PHP.

Anyway, presumably because there's no real difference between PECL and PHP-maintained extensions, both can be found in the manual. That's why runkit's there - it's not part of PHP proper, but it is on PECL. It might seem strange to group things into the manual that aren't officially maintained by PHP, but most of PHP's core extensions need separately installing anyway.

tl;dr: all the functions, classes and constants in PHP are defined by extensions, and the manual includes extensions that aren't part of PHP proper. PHP in most distributions only ships with a few of these enabled. runkit isn't part of PHP.

Re: Things to commit just before leaving your job

#129
Back in the bad old days of Visual SourceSafe I believe it was possible to perform a "commit time bomb" by rolling your computer's clock forward a couple months before committing. The VSS backend would not enact the commit until the server's clock caught up to the commit's timestamp. D:

Re: Things to commit just before leaving your job

#130

Earlier quoted context omitted.

Not some - all* US jurisdictions. From the Computer Fraud and Abuse Act (18 U.S. Code § 1030(5)(A)): >knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer

English isn't my first language, and I don't live in America so it's not like this matters to me, but now I'm curious. How is editing a source file you're meant to be editing "transmitting" anything?

The key is "without authorization". You're allowed to fix things and add features, but deliberate sabotage is arguably unauthorized. You might win in court, but as others said elsewhere, court is Too Expensive even if you win.

That, and I wouldn't be surprised if they didn't go after you for industrial espionage or something.

Post reply on HN