I just changed the password to some long random string so I’d never be tempted to log in again. Lack of password recovery isn’t a bug there, it’s a feature.
Ethanol has been produced for ages. It is ridiculous and unwise to call it "first-generation ethanol" or even "first-generation-process ethanol". The fact is that they had no green solution for gasoline production, so they used something that seemed green and was much more expensive, then funded the oil companies to use it, but there was no way it was a viable alternative, and it promised to tear up the environment by forcing excessive corn farming for a demand that could never be met.
We need to focus on energy R&D, not stopgaps and unviable energy solutions. In the meantime, if you want green, do everything you can to support teleworking.
"Engineers are pretty nice people, and they assume the rest of the world is pretty nice like them," said McAfee. "But that's not the way most people are. And if you build (software) assuming that's the way people are, it will get heavily spammed. So one of the roles that economics plays at Yahoo and other tech companies is to be just a little more suspicious about human nature."
I thought that was what security was for, not economists.
Sure. If someone took the time to write a book about what s/he thinks, and I don't mean teaching some subject (including their experiences in the subject), or writing some other fiction other non-fiction, but rather some semi-informed garbage providing only their opinion ("What I Think About ...", "Everything I Believe", or "My Autobiography"), then s/he is a substantial amount of time on a throwaway work. This is different than responding with opinion on HN, etc. because it isn't a discussion where they might actually engage someone else; it is a one-way conversation. Now if they wrote a wise work of art and is marketed correctly or widely popular, I might reconsider, but that probably isn't the case. I don't want someone who wrote a book like that and flaunting it in conversation working for me, because unless they are applying to a position as an editorialist, I don't want to read their diatribe emails or listen to soliloquies about their feelings on various subjects while at work, I want them to get their work done.
Why is a resume that shows understanding of the business important? Because it shows that they are focused on what is important to the work and relaying that information, rather than their opinion.
I'm against the death penalty also, but this is misleading. Just look at Central America, parts of South America and parts of Africa. There are and have been many, many killings by the government in these places for the purpose of keeping its constituents under control.
Self-publishing a mini e-book that shares your perspective with the world
This would be a definite "minus" in my book in a potential employee, unless I was hiring an editorialist. Instead, I would want to see results and understanding of the business. I agree that a resume doesn't do that justice, but it helps when done correctly.
Retry would work for small time differences, but would mean greater delay (and subsequent "I give up"), if the system clock were to be set backwards a substantial amount.
def nextId(): Long = synchronized {
var timestamp = timeGen()
if (lastTimestamp > timestamp) {
log.warning("clock is moving backwards. Rejecting requests until %d.", lastTimestamp);
throw new InvalidSystemClock("Clock moved backwards. Refusing to generate id for %d milliseconds".format(lastTimestamp - timestamp));
}
Does that mean that the inability to tweet grinds to a halt if the system clock gets set back? That could be a problem whenever the server time is being sync'd with the time server and is running ahead (or if time server goes down/connection goes down- it happens), etc. I know there would be other issues too, but this seems a little fishy.
Not legal advice for sure and take it with a grain of salt, but first I'd:
- Get all of the evidence you can that you distributed it first. If this requires contacting another company to confirm records of when you made it available, do that first to have it ready.
- Contact the FSF, send them that evidence, and ask what you can do/should do.
- Send a summary of the evidence you have (or at least some of it, and depending on what the FSF folks suggest) to the person, telling them you wish them to stop selling your script. They will probably stop.
If that doesn't work and FSF couldn't help I'd either:
1. Attack via social networking. Blog, comment, tweet, etc. the hell out of it in areas you know will affect his/her market, linking to your free source.
I personally don't think options are usually a good deal unless you believe that you'll be working for the next Google, Facebook, etc. I worked for a company that was hot as pizza cheese on your gums straight from the oven, but I didn't take options because of past experience and advice from others, and in the end, I was glad that I didn't. Despite its growth, it mostly fizzled, and in the process of that growth, it took on a great deal of investment, and those options were diluted like nobody's business.
But, if you really like the opportunity and believe in it, and your family isn't sacrificed, then go for it. You only live once (well at least that's what I believe).
I can't believe that the interviewer is asking the interviewee to implement a sorting algorithm and is making fun of candidates online. That certainly is not a place that I'd want to work.
In GitHub, that's not the case. People often fork Rails, etc. to make a change that they need locally but will push that (easily) back up to the main project for consideration. Forking allows you and others to easily work with your patched version without even having to wait on the original project. For the project owner that wants sole control of a project, GitHub might not be the right choice. But for those that want other to easily be able to make changes and provide those changes to others, GitHub is great.
I'm all for going just what needs to be done, but I think you are not giving good advice about "hiring scrubs". I worked for a successful company that had a younger less experienced developer write the original code. But he was not a "scrub". His code could have easily have been written by another developer with a few more years experience. Yes, he made some rookie mistakes in the code, but it worked and was close enough to keep the company going.
However, you often get what you pay for, and that goes for both hiring inexperienced developers and offshore/contracted development.
If you do hire young/inexperienced, make sure they have a mentor that enforces good practices or have code review/are pairing and that these developers seem to be learning good practices.
There is a difference between bad and "good enough".
Going to do the same thing. See ya, HN.