One of the things people do with it is build base boxes, which are preconfigured virtual machines, and share those base boxes for other people to build upon. In order to do so, the people who receive these base boxes need the private keys they are configured with.
You could distribute the private keys with the base boxes, I suppose, but then you are stuck sharing multiple files instead of just one, and you can't install a base box by running one single command with a URL argument any more. It increases the complexity.
Example: the keys for Vagrant. Vagrant is a system for managing virtual machines for development purposes. The ssh keys are used to facilitate passwordless login. They aren't typically exposed to the outside world, and they are clearly labelled as insecure.
The F18 release documentation is pretty clear on the fact that the new installer UI is a first cut and still has rough edges
Turning out unfinished, buggy work and saying it's okay because you told people it was unfinished and buggy seems to me to be an attitude that is incompatible with ever releasing a high quality product.
And Safari will be broken In 3... 2... 1... At least that's what would happen when Steve was alive.
That would be the same Steve that told everybody that the official way of getting apps onto the iPhone was through web apps when he first launched it?
Mobile Safari and web apps have always been a vital part of the iPhone. It changed the mobile web landscape completely, because it was the first popular mobile phone with a desktop-class web browser built in. Your revisionist history implying that Steve would happily throw Mobile Safari under the bus to hurt a competitor is at odds with history.
Along with an explanation that the Amazon Web app was compromising stability and user experience.
Presumably you are referring to mobile Flash. I think it's abundantly clear that this was actually the case and not an anti-competitive move. Even Android and Adobe dropped mobile Flash.
Yes, I'm responsible for hiring developers where I work now and at my last job. If the candidate doesn't have any appropriate sample code, I'm in favour of small sample projects that represent the kinds of things they'll be working on. But I don't think they should be timed, and I think FizzBuzz and similar are next to useless.
Firstly, the nature of the task: multiple choice, trivia, FizzBuzz, things like that are useless. As somebody else pointed out, you can be language savvy while still being a crap developer (and vice-versa, for example if you're working in a field where IDE support is commonplace). You can't judge how good a developer is with a series of yes/no questions, or where there's a single correct algorithm to use, or where no judgement calls have to be made. That is the stuff you use to weed out the complete morons - but I don't want to weed out the complete morons, I want to weed out average developers and below.
If you want to judge how good a developer is, you have to give them a problem where they have a fair amount of freedom to make decisions. You can see how they structure a real project, what their commit log messages are like, whether they chose to write tests, etc. It invites questions like why they chose one architectural style over another, why they chose one library over another, etc.
How long they took to do this is irrelevant because every candidate is going to put a different amount of effort in, making I wouldn't be comparing like for like if I judged them on time.
Furthermore, once you introduce timed tasks, you either have to use one of those really crappy web widgets and simplify your questions down so much that they are useless, or you have to bring them into the office, which is guaranteed to waste at least somebody's time.
You want to see sample code? Fine. You want stupid timed tests? No, that's a sign of a crappy hiring process that is ill suited for finding quality developers.
I'm not sure you got what I was saying. I agree with that. What I was saying was that some developers will incorrectly perceive simple and clear code as incomprehensible and unclear, simply because it uses language constructs that they aren't familiar with and they don't like stepping out of their comfort zone to learn new things.
Let me give an example: A co-worker had many years of experience with C, yet it was all pretty basic stuff. We hired her to work on iOS projects. She could cope with everything that looked like C, and the basic Objective-C message-passing syntax, but as soon as anybody on the team used blocks, she complained that it was incomprehensible. It didn't matter how clear the code was, it didn't matter if converting it to her style made it much more complex and difficult to read, it didn't matter if the alternative had already been deprecated by Apple, if it used blocks, she called it bad code. The problem was with her, not with the code.
Now if you say something like "One developer complained that it was unclear, therefore the code is bad" in that kind of situation, you tie yourself in knots rewriting good code into bad and the entire team is beholden to the foibles of each individual developer.
If I'm senior coder, than that means I set the standard.
Older doesn't necessarily mean more senior developer. I've had to fire somebody who has been programming a couple of decades longer than I have because they weren't up to scratch. I was the one writing the standard too. Call me a snot-nosed brat if you like, but that doesn't change the fact he couldn't get the job done.
There are developers who have 20 years experience, and there are developers that have 1 year of experience that they've repeated 20 times. The two are not equivalent, and just because they've been doing it a long time, it doesn't necessarily mean they are any good at it.
If other programmers can not understand it, then it's bad.
True, but what we have here is the opinion of one programmer. I've worked with people who have many years of experience, but it was all mostly the same sort of stuff, and whenever they were confronted with anything that didn't fit with what they were used to, they'd label it "incomprehensible" or "messy", when really, what they meant was "I've not used this language construct/idiom/design pattern before, I want to do it like I've always done it".
Now reading the submission, it doesn't sound like that's the case here, but I'd be wary of jumping to the conclusion that just because one developer has voiced a problem with some code, that the default assumption should be that it's the code at fault.
Re:Oh, great, exactly what I don't want...
on
Ubuntu Phone OS Unveiled
·
· Score: 3, Informative
I hate the way iOS has gradually made it harder and harder for me to interact with the app I have open rather than the OS. Dragging from screen edge, tapping with the wrong number of fingers... All sorts of things get eaten by the OS, so I end up doing something other than interacting with the app.
Settings > General > Multitasking Gestures > Off. That leaves swiping from the top edge to open Notification Center. I can't think of any other interaction mechanism that iOS intercepts. Tapping with the wrong number of fingers doesn't do anything, unless perhaps you've switched on some accessibility feature by mistake?
It's got nothing to do with micro-transactions, it's about lock-in. They bought a good that can only be used in conjunction with a service from a single vendor. If that vendor decides to stop offering the service, the problem arises because the entire utility of the good is tied to that service. How exactly they paid for the good is irrelevant. It's the fact that they can't continue to use the good independently of the vendor they bought it from.
Actually, copyright was originally a censorship mechanism for the Crown. It's true that there was a transformative change to protect authors with the Statute of Anne, but there were laws in place before then you could fairly refer to as copyright law.
The brand managers who commission stuff like this are typically inexperienced, low-paid and overworked. They don't know what the fuck they are doing but they know they've got to get it done quickly and for next to no money. You'd be shocked at how low the budgets they have to work with are for digital stuff - sure, drop a couple of hundred grand on a music video to promote their latest single, but good luck getting more than ten grand for a website that they'll be using for years. They also have the habit of following the crowd and simply using the suppliers and techniques their colleagues use. So it doesn't surprise me that a few of them decided to use cheap off-shored clicks to inflate their results, or that once a few of them did it, it spread like wildfire within their ranks.
It is funny though when somebody sees me typing at full speed not realising that autocompletion is increasing my output by a factor of 3-4. Also: Hacker Typer.
My guess is that they developed a functional prototype
They started the project on the back of rumours, before Apple had officially announced the connector, before anybody had a chance to get their hands on a connector and tear it down, so I'm guessing they didn't have a clue how to even start.
But that semantic point wasn't the important part, it was merely a tool to point out the source of the problem -- just like you said, Apple.
I didn't say that Apple was the source of the problem, I said it didn't matter for the purpose of what I was saying.
Think of it this way: I set up a Kickstarter taking people's money for an open-source release of Windows. I do this before I attempt to negotiate a license to do this with Microsoft. Now, theoretically speaking, I am able to follow through on this - I can set up servers and a website for the downloads, I've got everything I need to actually do the job - I just need a license from Microsoft, right? So when Microsoft say no, is it their fault or mine that my project fails?
No, it didn't turn out they couldn't build it, it turned out Apple wouldn't let them build it
They couldn't build it because they need a license from Apple and Apple won't give them one. Whether you want to blame Apple or not, the fact remains that they took money for something that they couldn't build.
[Link to "Apple Now Most Valuable Company in History"]
That was then. This is now. Apple is already in decline.
By what measurement?
People are annoyed at the things Apple will not allow.
People have been annoyed at the things Apple will not allow for years. This is nothing new.
The iPhone 5 is not quite the wait-in-line-for-weeks thing that its predecessors were.
Apple just had a record-breaking launch of the iPhone 5 in China last weekend. When the iPhone 5 was first launched, it sold 5 million in its first weekend. The iPhone 4S sold 4 million in its first weekend. The iPhone 4 sold 1.7 million in its first weekend.
The public knows all too well why Apple took away Google maps
Because their license was ending and Google's terms weren't acceptable to Apple?
MBAs now run Apple. They prefer to make "safe choices" unlike Steve Jobs.
Tim Cook runs Apple. He's actually been running Apple for a long time, long before Steve Jobs died. He's just implemented a major restructuring of Apple's divisions. And you've just got done complaining about the risk Apple took with Maps.
They took money for a product they didn't know if they could build, then when it turns out they couldn't, instead of slightly modifying the design by including a female USB port, they set customers up with accounts on their Kickstarter competitor to refund them. This looks pretty much like they changed their mind about building it if favour of pivoting their business to go into crowd funding, and decided to use Apple hate to grab users and publicity.
It is by no means finalised. This is like a beta. It's feature complete, now they've got to shake out the interoperability bugs between implementations. During this phase, they can discover that there are flaws or omissions within the specification, which will entail changes to the specification. When they have multiple interoperable implementations, then it will be finalised.
Slashdot Mirror
One of the things people do with it is build base boxes, which are preconfigured virtual machines, and share those base boxes for other people to build upon. In order to do so, the people who receive these base boxes need the private keys they are configured with.
You could distribute the private keys with the base boxes, I suppose, but then you are stuck sharing multiple files instead of just one, and you can't install a base box by running one single command with a URL argument any more. It increases the complexity.
Example: the keys for Vagrant. Vagrant is a system for managing virtual machines for development purposes. The ssh keys are used to facilitate passwordless login. They aren't typically exposed to the outside world, and they are clearly labelled as insecure.
I agree.
Turning out unfinished, buggy work and saying it's okay because you told people it was unfinished and buggy seems to me to be an attitude that is incompatible with ever releasing a high quality product.
That would be the same Steve that told everybody that the official way of getting apps onto the iPhone was through web apps when he first launched it?
Mobile Safari and web apps have always been a vital part of the iPhone. It changed the mobile web landscape completely, because it was the first popular mobile phone with a desktop-class web browser built in. Your revisionist history implying that Steve would happily throw Mobile Safari under the bus to hurt a competitor is at odds with history.
Presumably you are referring to mobile Flash. I think it's abundantly clear that this was actually the case and not an anti-competitive move. Even Android and Adobe dropped mobile Flash.
I'd shut it down and give the money back to the shareholders.
No, they should return 4 - it's guaranteed to be random.
Yes, I'm responsible for hiring developers where I work now and at my last job. If the candidate doesn't have any appropriate sample code, I'm in favour of small sample projects that represent the kinds of things they'll be working on. But I don't think they should be timed, and I think FizzBuzz and similar are next to useless.
Firstly, the nature of the task: multiple choice, trivia, FizzBuzz, things like that are useless. As somebody else pointed out, you can be language savvy while still being a crap developer (and vice-versa, for example if you're working in a field where IDE support is commonplace). You can't judge how good a developer is with a series of yes/no questions, or where there's a single correct algorithm to use, or where no judgement calls have to be made. That is the stuff you use to weed out the complete morons - but I don't want to weed out the complete morons, I want to weed out average developers and below.
If you want to judge how good a developer is, you have to give them a problem where they have a fair amount of freedom to make decisions. You can see how they structure a real project, what their commit log messages are like, whether they chose to write tests, etc. It invites questions like why they chose one architectural style over another, why they chose one library over another, etc.
How long they took to do this is irrelevant because every candidate is going to put a different amount of effort in, making I wouldn't be comparing like for like if I judged them on time.
Furthermore, once you introduce timed tasks, you either have to use one of those really crappy web widgets and simplify your questions down so much that they are useless, or you have to bring them into the office, which is guaranteed to waste at least somebody's time.
You want to see sample code? Fine. You want stupid timed tests? No, that's a sign of a crappy hiring process that is ill suited for finding quality developers.
They are extremely valuable - they let you know which potential employers don't have a clue about programmer productivity / expertise.
At first glance his sources and reasoning seem solid enough. Can you elaborate?
I'm not sure you got what I was saying. I agree with that. What I was saying was that some developers will incorrectly perceive simple and clear code as incomprehensible and unclear, simply because it uses language constructs that they aren't familiar with and they don't like stepping out of their comfort zone to learn new things.
Let me give an example: A co-worker had many years of experience with C, yet it was all pretty basic stuff. We hired her to work on iOS projects. She could cope with everything that looked like C, and the basic Objective-C message-passing syntax, but as soon as anybody on the team used blocks, she complained that it was incomprehensible. It didn't matter how clear the code was, it didn't matter if converting it to her style made it much more complex and difficult to read, it didn't matter if the alternative had already been deprecated by Apple, if it used blocks, she called it bad code. The problem was with her, not with the code.
Now if you say something like "One developer complained that it was unclear, therefore the code is bad" in that kind of situation, you tie yourself in knots rewriting good code into bad and the entire team is beholden to the foibles of each individual developer.
Older doesn't necessarily mean more senior developer. I've had to fire somebody who has been programming a couple of decades longer than I have because they weren't up to scratch. I was the one writing the standard too. Call me a snot-nosed brat if you like, but that doesn't change the fact he couldn't get the job done.
There are developers who have 20 years experience, and there are developers that have 1 year of experience that they've repeated 20 times. The two are not equivalent, and just because they've been doing it a long time, it doesn't necessarily mean they are any good at it.
True, but what we have here is the opinion of one programmer. I've worked with people who have many years of experience, but it was all mostly the same sort of stuff, and whenever they were confronted with anything that didn't fit with what they were used to, they'd label it "incomprehensible" or "messy", when really, what they meant was "I've not used this language construct/idiom/design pattern before, I want to do it like I've always done it".
Now reading the submission, it doesn't sound like that's the case here, but I'd be wary of jumping to the conclusion that just because one developer has voiced a problem with some code, that the default assumption should be that it's the code at fault.
Previously on Slashdot: Could You Pass Harvard's Entrance Exam From 1869?
Settings > General > Multitasking Gestures > Off. That leaves swiping from the top edge to open Notification Center. I can't think of any other interaction mechanism that iOS intercepts. Tapping with the wrong number of fingers doesn't do anything, unless perhaps you've switched on some accessibility feature by mistake?
It's got nothing to do with micro-transactions, it's about lock-in. They bought a good that can only be used in conjunction with a service from a single vendor. If that vendor decides to stop offering the service, the problem arises because the entire utility of the good is tied to that service. How exactly they paid for the good is irrelevant. It's the fact that they can't continue to use the good independently of the vendor they bought it from.
Actually, copyright was originally a censorship mechanism for the Crown. It's true that there was a transformative change to protect authors with the Statute of Anne, but there were laws in place before then you could fairly refer to as copyright law.
The brand managers who commission stuff like this are typically inexperienced, low-paid and overworked. They don't know what the fuck they are doing but they know they've got to get it done quickly and for next to no money. You'd be shocked at how low the budgets they have to work with are for digital stuff - sure, drop a couple of hundred grand on a music video to promote their latest single, but good luck getting more than ten grand for a website that they'll be using for years. They also have the habit of following the crowd and simply using the suppliers and techniques their colleagues use. So it doesn't surprise me that a few of them decided to use cheap off-shored clicks to inflate their results, or that once a few of them did it, it spread like wildfire within their ranks.
It is funny though when somebody sees me typing at full speed not realising that autocompletion is increasing my output by a factor of 3-4. Also: Hacker Typer.
-- John Gilmore
They started the project on the back of rumours, before Apple had officially announced the connector, before anybody had a chance to get their hands on a connector and tear it down, so I'm guessing they didn't have a clue how to even start.
I didn't say that Apple was the source of the problem, I said it didn't matter for the purpose of what I was saying.
Think of it this way: I set up a Kickstarter taking people's money for an open-source release of Windows. I do this before I attempt to negotiate a license to do this with Microsoft. Now, theoretically speaking, I am able to follow through on this - I can set up servers and a website for the downloads, I've got everything I need to actually do the job - I just need a license from Microsoft, right? So when Microsoft say no, is it their fault or mine that my project fails?
They couldn't build it because they need a license from Apple and Apple won't give them one. Whether you want to blame Apple or not, the fact remains that they took money for something that they couldn't build.
There is, it's called "fair dealing".
By what measurement?
People have been annoyed at the things Apple will not allow for years. This is nothing new.
Apple just had a record-breaking launch of the iPhone 5 in China last weekend. When the iPhone 5 was first launched, it sold 5 million in its first weekend. The iPhone 4S sold 4 million in its first weekend. The iPhone 4 sold 1.7 million in its first weekend.
Because their license was ending and Google's terms weren't acceptable to Apple?
Tim Cook runs Apple. He's actually been running Apple for a long time, long before Steve Jobs died. He's just implemented a major restructuring of Apple's divisions. And you've just got done complaining about the risk Apple took with Maps.
They took money for a product they didn't know if they could build, then when it turns out they couldn't, instead of slightly modifying the design by including a female USB port, they set customers up with accounts on their Kickstarter competitor to refund them. This looks pretty much like they changed their mind about building it if favour of pivoting their business to go into crowd funding, and decided to use Apple hate to grab users and publicity.
It is by no means finalised. This is like a beta. It's feature complete, now they've got to shake out the interoperability bugs between implementations. During this phase, they can discover that there are flaws or omissions within the specification, which will entail changes to the specification. When they have multiple interoperable implementations, then it will be finalised.