I'm certain the people who started the project were well aware that work would be involved. You can't fault them for other people's unrealistic expectations.
Their repossession is probably illegal, or contract breach anyway.
At least done under "false claims / terms."
Yeah, I suspect the same thing. Maybe he also got his money back for the unused term of the lease. I expect that might be legal.
What I find amusing and also quite irritating is the barely suppressed gleeful tone of the article. It's clear where the article writer's sentiment lies.
The lesson here is that you should own your own stuff. No DRM, no Apple overlord deciding what you should and shouldn't be able to install, no leases, even if the lease term is a single payment for a lease in perpetuity. You should own it, it should be yours to do exactly and precisely what you want with.
I think some of the people who replied to me had really good points and suggestions for how this approach might be done better than I described as well.
One caveat. Keep the benefit a bit more watered down than above. When dealing with management, keep it simple, and meaningful to them, not to you. Talking about validating a form field or whatnot isn't a good way to go about it. Talk about the lost time and productivity, potential impact while troubleshooting and finding root cause, etc.
This is likely true. My technical nature betrays me here.:-)
But I think the most important thing is to use a story. Explain it in stories and scenarios that are geared towards their worldview.
So, let's say we're working on the website and the code behind it. We push out some new code one day, and a few days later, after we've already started working on a bunch of other stuff, someone reports a bug. One of the form fields isn't validating correctly.
But, we've been working on that form already. We can't really tell if the bug is still there, or if maybe it was something that was wrong that got moved around. We also can't tell how the bug got there in the first place. That's because we don't know what the old code looked like exactly anymore.
But, suppose we had a version control system.... Then, when we push new code out to the site, we know exactly which version we push. When someone reports a problem, we can easily go back to that version in a testing environment to find the problem for ourselves and figure out exactly what's causing it. And then, once we've determined the cause, we can analyze the history (because we've been keeping a history of everything we do) to figure out how the problem got there in the first place so we can do better next time.
There you've explained how it helps you. You no longer need them to understand what it is exactly. You've just explained why it would be good for them to get it for you, and that's all they really care about anyway. They don't want to understand what it is. Understanding stuff like that is why they hired you in the first place.
I'm a strong proponent of sending developers to meet directly with customers and see what they're doing in their environment. But I think that's a separate issue from installation, deployment and setup. It should be made absolutely clear to a developer that if they're troubleshooting they need to be extra vigilant about making sure that whatever they did is documented thoroughly so it can be replicated elsewhere, or so others can pick up where they left off with that customer.
My advice though was mainly geared towards places where the customer is at a remove. Mainly web app shops, though it can also be applied (with modifications) to shrink-wrap software (which includes Open Source package manager packages).
I think there is something to be said for three environments. Developer test where developers do their own deployment, QA test, where another team does the deployment, and production. I think that the developer test environment should be further restricted so developers do not have the freedom to fiddle the deployment after the fact. You provide the package, hit the button, and if it doesn't deploy properly you have to fix your package and try to deploy it again.
It's possible that you cannot make a deployment process as simple has pressing the 'deploy' button after specifying a single package file. But if that's the case, you should strive for that level of simplicity and give the developer the absolute minimum permissions necessary to do whatever it is that is needed. No hand-fiddling the software after the set process is finished.
I think this is a really good way of thinking about it. Because sometimes it does really serve the organization's needs the best to push a change without adequate testing. It's just much less often than the developer generally thinks it is. And you're right, this separation of roles keeps everybody honest.
My answer is mostly 'no'. The only benefit I see is that developers will become more motivated to have a simpler and better installation process. And that's a pretty nifty benefit.
But I've been on both sides of the fence. I've rarely been a developer who did anything less than thorough testing before declaring something 'done'. But I know that I'm an incredible rarity in that way. And on the devops side of things, the less ability developers have to push things, the more likely decent QA will get done before stuff ends up in production. But developers frequently also give you installation instructions that are unrepeatable special case installs with rollback instructions that make no sense.
I think that one good way to balance this is to have a preliminary test environment into which developers are allowed to push things. They are given limited rights to this environment, basically just the ability to upload some software and run a deployment script. This encourages them to write functioning deployment scripts. But it prevents them from shoving things into production because it just 'has' to go out today and it's such a small, low-risk thing. Of course it'll work!
This 'religious tolerance' thing is exactly what these rioting mobs are not demonstrating. Religious tolerance does not mean that you don't have to hear anything you don't like about your religion. It means that you do not suffer political or economic repression for your religious beliefs. That's it.
So I'm sorry (well, no, I'm not really) but no. This absolutely will not fly. I don't care what kind of weaponry people who think rioting over an insult to their religion acquire. They must never be allowed control under any circumstances. This kind of behavior is flat out unacceptable and intolerable. I will never in any way support it and nobody else should either.
Fix your own worldview, because you will not get to impose it on everybody else. I will never agree to it.
Also, all the supporting code was under GPL. The code that pulled everything together to make a distribution. And XBian wasn't posting that code. That's a hard requirement of the GPL. Attribution actually isn't a hard requirement of the GPL, it's just polite.
My guess is that they didn't want to release the code because, perhaps, they didn't have any, or perhaps because it was all chewing gum and bailing wire and they didn't even have it under source control.
And this reads a little like one developer trying to use the GPL to prevent a fork.
But, given the seeming quality of the distribution and level of response from the XBian people, I do not think that in this case it is any great loss.
Eventually the ice over Greenland will melt. It will take a bit longer, but 'bit' is on the order of a few years maybe, not decades or centuries. Then you'll see some of your sea level change, though it won't be quite so dramatic even still.
As someone pointed out, the biggest issue with arctic ice melting is the lowering of the Earth's albedo, causing it to absorb significantly more energy from sunlight. This will accelerate the warming trend and may cause significant parts of the antarctic to start melting. And almost all of that ice is ice on the ground, not water, and that WILL cause very dramatic sea level changes.
Neither. At least, I don't think either. How can you spend the same money on both things? Money isn't generally supposed to work that way the last I heard.
The Apollo program takes X money. It isn't going to take any less because someone wishes for it to. And it's not like there's an infinite supply of the stuff either.
I keep it in a Mercurial repository and use symlinks into the repository to deploy it. I also make free use of Mercurial's subrepo feature for tools that others wrote that are not yet found as packages on the Linux distributions I use.
Yes, there is still a testing issue. For most of this code it's not a big deal because I'm the only user. I test it as I write it with a few simple hand tests and then it's good to go.
If I were doing this for something where the code mattered to other people I would just add unit tests for various subsections as made sense. I would also start sectioning off the tools and making them into separate repositories of their own. I'd also make much sparer use of the sub-repo feature and instead have deployment scripts that handled making sure the correct version was in place.
You still need test environments though for integration testing. And as the code grows, ad-hoc test environments stop being very practical. You should dedicate a VM or two (or even a machine or two) to replicating miniature versions of the real-world setups the code is expected to work in.
Lastly, it's never too early to start using source control on your code. 98% of my code is under source control, even most stuff I think is 'throwaway' or ad-hoc.
I would also strongly recommend Mercurial (or git (if you must)) over Bazaar. It's faster, and the mental model those two tools encourage is a much more accurate representation of what they're really doing. Bazaar lets you pretend that branching is still a big deal and takes some effort to resolve. It lets you continue to think in the model of centralized source systems even though it's not. You will be doing yourself a huge favor in productivity (yes, even for a single developer) to not use it and go for something that doesn't let you pretend anymore. Of those tools, I think Mercurial has a far more carefully thought out and better set of commands and options than git does.
Interesting. If I wanted to reduce your karma, that's exactly what I'd do. Comments that are getting up-modded are likely to just be up-modded again, and so wouldn't have any effect at all. But comments that didn't get up-modded are ones nobody is really paying attention to, and so would likely stay down-modded and you'd take the hit to your karma.
My guess is that it was a single user, or small cabal of users who were doing this. And I'm also guessing the editors then told them to knock it off, or took away their mod privileges for abuse. Usually, when you take action against someone, you don't tell the complainer unless it was really egregious, partly to prevent complainers from gaming the system.
I have taken a pounding once or twice. And then they went and found all of my other comments on completely unrelated topics and down-modded them too. And I still have excellent karma.:-)
But launching a rocket into space have pretty huge and mostly irreducible forces acting against you. Air resistance and gravity. Launching something into space is always going to cost a LOT of fuel, in a world were fuel is quickly dwindling. We are never going to have solar powered rockets, or even nuclear.
Fuel can be manufactured using renewable energy, and it doesn't have to be hydrocarbon based anyway. So that's a bit of a red herring.
But you are correct about the rest of it. Though I think there's still a long way to go in efficiency improvement.
I suspect that having humans actively in space will increase the economic value of finding better solutions for getting people into orbit that aren't so fuel hungry and/or dangerous.
Though really, I think the best move was getting that out of NASA's hands. NASA appeared to be becoming an organization that was unwilling to take risks or consider new ideas. And management there appeared more interested in blame shifting and PR than actually solving problems. The Challenger disaster and the unwillingness of management to take any blame for constantly decreasing safety margins in an attempt to make sure all launches happened on time is a case in point.
Ahh, so you spend a dollar on the Apollo program, and then that same dollar on a poverty reduction program? How does that work? Do you counterfeit it or something? Won't that cause inflation?
Slashdot Mirror
I'm certain the people who started the project were well aware that work would be involved. You can't fault them for other people's unrealistic expectations.
Well, they weren't intending to advertise nearly as widely as they did. I wouldn't fault the project creators for what happened.
Their repossession is probably illegal, or contract breach anyway. At least done under "false claims / terms."
Yeah, I suspect the same thing. Maybe he also got his money back for the unused term of the lease. I expect that might be legal.
What I find amusing and also quite irritating is the barely suppressed gleeful tone of the article. It's clear where the article writer's sentiment lies.
The lesson here is that you should own your own stuff. No DRM, no Apple overlord deciding what you should and shouldn't be able to install, no leases, even if the lease term is a single payment for a lease in perpetuity. You should own it, it should be yours to do exactly and precisely what you want with.
Or bitbucket! :-) I'm a big Mercurial fan. :-)
I think some of the people who replied to me had really good points and suggestions for how this approach might be done better than I described as well.
Particularly this one, and this one about focusing on costs.
One caveat. Keep the benefit a bit more watered down than above. When dealing with management, keep it simple, and meaningful to them, not to you. Talking about validating a form field or whatnot isn't a good way to go about it. Talk about the lost time and productivity, potential impact while troubleshooting and finding root cause, etc.
This is likely true. My technical nature betrays me here. :-)
But I think the most important thing is to use a story. Explain it in stories and scenarios that are geared towards their worldview.
First, you should've added a 'Mercurial' tag. :-)
Explain what it will do for them. For example...
So, let's say we're working on the website and the code behind it. We push out some new code one day, and a few days later, after we've already started working on a bunch of other stuff, someone reports a bug. One of the form fields isn't validating correctly.
But, we've been working on that form already. We can't really tell if the bug is still there, or if maybe it was something that was wrong that got moved around. We also can't tell how the bug got there in the first place. That's because we don't know what the old code looked like exactly anymore.
But, suppose we had a version control system.... Then, when we push new code out to the site, we know exactly which version we push. When someone reports a problem, we can easily go back to that version in a testing environment to find the problem for ourselves and figure out exactly what's causing it. And then, once we've determined the cause, we can analyze the history (because we've been keeping a history of everything we do) to figure out how the problem got there in the first place so we can do better next time.
There you've explained how it helps you. You no longer need them to understand what it is exactly. You've just explained why it would be good for them to get it for you, and that's all they really care about anyway. They don't want to understand what it is. Understanding stuff like that is why they hired you in the first place.
I'm a strong proponent of sending developers to meet directly with customers and see what they're doing in their environment. But I think that's a separate issue from installation, deployment and setup. It should be made absolutely clear to a developer that if they're troubleshooting they need to be extra vigilant about making sure that whatever they did is documented thoroughly so it can be replicated elsewhere, or so others can pick up where they left off with that customer.
My advice though was mainly geared towards places where the customer is at a remove. Mainly web app shops, though it can also be applied (with modifications) to shrink-wrap software (which includes Open Source package manager packages).
I think there is something to be said for three environments. Developer test where developers do their own deployment, QA test, where another team does the deployment, and production. I think that the developer test environment should be further restricted so developers do not have the freedom to fiddle the deployment after the fact. You provide the package, hit the button, and if it doesn't deploy properly you have to fix your package and try to deploy it again.
It's possible that you cannot make a deployment process as simple has pressing the 'deploy' button after specifying a single package file. But if that's the case, you should strive for that level of simplicity and give the developer the absolute minimum permissions necessary to do whatever it is that is needed. No hand-fiddling the software after the set process is finished.
I think this is a really good way of thinking about it. Because sometimes it does really serve the organization's needs the best to push a change without adequate testing. It's just much less often than the developer generally thinks it is. And you're right, this separation of roles keeps everybody honest.
My answer is mostly 'no'. The only benefit I see is that developers will become more motivated to have a simpler and better installation process. And that's a pretty nifty benefit.
But I've been on both sides of the fence. I've rarely been a developer who did anything less than thorough testing before declaring something 'done'. But I know that I'm an incredible rarity in that way. And on the devops side of things, the less ability developers have to push things, the more likely decent QA will get done before stuff ends up in production. But developers frequently also give you installation instructions that are unrepeatable special case installs with rollback instructions that make no sense.
I think that one good way to balance this is to have a preliminary test environment into which developers are allowed to push things. They are given limited rights to this environment, basically just the ability to upload some software and run a deployment script. This encourages them to write functioning deployment scripts. But it prevents them from shoving things into production because it just 'has' to go out today and it's such a small, low-risk thing. Of course it'll work!
This 'religious tolerance' thing is exactly what these rioting mobs are not demonstrating. Religious tolerance does not mean that you don't have to hear anything you don't like about your religion. It means that you do not suffer political or economic repression for your religious beliefs. That's it.
So I'm sorry (well, no, I'm not really) but no. This absolutely will not fly. I don't care what kind of weaponry people who think rioting over an insult to their religion acquire. They must never be allowed control under any circumstances. This kind of behavior is flat out unacceptable and intolerable. I will never in any way support it and nobody else should either.
Fix your own worldview, because you will not get to impose it on everybody else. I will never agree to it.
Yes, I thought perhaps that the OP was trying to come up with a convincing cover story for wanting to play the hot coffee mod on GTA.
Also, all the supporting code was under GPL. The code that pulled everything together to make a distribution. And XBian wasn't posting that code. That's a hard requirement of the GPL. Attribution actually isn't a hard requirement of the GPL, it's just polite.
You can't fool us. This story is a giant troll to get your ridiculous username in front of as many people as possible.
OH NOES! I've been forced to expand my vocabulary! The pain in my head is killing me, please make it stop!
My guess is that they didn't want to release the code because, perhaps, they didn't have any, or perhaps because it was all chewing gum and bailing wire and they didn't even have it under source control.
And this reads a little like one developer trying to use the GPL to prevent a fork.
But, given the seeming quality of the distribution and level of response from the XBian people, I do not think that in this case it is any great loss.
Eventually the ice over Greenland will melt. It will take a bit longer, but 'bit' is on the order of a few years maybe, not decades or centuries. Then you'll see some of your sea level change, though it won't be quite so dramatic even still.
As someone pointed out, the biggest issue with arctic ice melting is the lowering of the Earth's albedo, causing it to absorb significantly more energy from sunlight. This will accelerate the warming trend and may cause significant parts of the antarctic to start melting. And almost all of that ice is ice on the ground, not water, and that WILL cause very dramatic sea level changes.
Neither. At least, I don't think either. How can you spend the same money on both things? Money isn't generally supposed to work that way the last I heard.
The Apollo program takes X money. It isn't going to take any less because someone wishes for it to. And it's not like there's an infinite supply of the stuff either.
I keep it in a Mercurial repository and use symlinks into the repository to deploy it. I also make free use of Mercurial's subrepo feature for tools that others wrote that are not yet found as packages on the Linux distributions I use.
Yes, there is still a testing issue. For most of this code it's not a big deal because I'm the only user. I test it as I write it with a few simple hand tests and then it's good to go.
If I were doing this for something where the code mattered to other people I would just add unit tests for various subsections as made sense. I would also start sectioning off the tools and making them into separate repositories of their own. I'd also make much sparer use of the sub-repo feature and instead have deployment scripts that handled making sure the correct version was in place.
You still need test environments though for integration testing. And as the code grows, ad-hoc test environments stop being very practical. You should dedicate a VM or two (or even a machine or two) to replicating miniature versions of the real-world setups the code is expected to work in.
Lastly, it's never too early to start using source control on your code. 98% of my code is under source control, even most stuff I think is 'throwaway' or ad-hoc.
I would also strongly recommend Mercurial (or git (if you must)) over Bazaar. It's faster, and the mental model those two tools encourage is a much more accurate representation of what they're really doing. Bazaar lets you pretend that branching is still a big deal and takes some effort to resolve. It lets you continue to think in the model of centralized source systems even though it's not. You will be doing yourself a huge favor in productivity (yes, even for a single developer) to not use it and go for something that doesn't let you pretend anymore. Of those tools, I think Mercurial has a far more carefully thought out and better set of commands and options than git does.
Interesting. If I wanted to reduce your karma, that's exactly what I'd do. Comments that are getting up-modded are likely to just be up-modded again, and so wouldn't have any effect at all. But comments that didn't get up-modded are ones nobody is really paying attention to, and so would likely stay down-modded and you'd take the hit to your karma.
My guess is that it was a single user, or small cabal of users who were doing this. And I'm also guessing the editors then told them to knock it off, or took away their mod privileges for abuse. Usually, when you take action against someone, you don't tell the complainer unless it was really egregious, partly to prevent complainers from gaming the system.
I have taken a pounding once or twice. And then they went and found all of my other comments on completely unrelated topics and down-modded them too. And I still have excellent karma. :-)
But launching a rocket into space have pretty huge and mostly irreducible forces acting against you. Air resistance and gravity. Launching something into space is always going to cost a LOT of fuel, in a world were fuel is quickly dwindling. We are never going to have solar powered rockets, or even nuclear.
Fuel can be manufactured using renewable energy, and it doesn't have to be hydrocarbon based anyway. So that's a bit of a red herring.
But you are correct about the rest of it. Though I think there's still a long way to go in efficiency improvement.
I suspect that having humans actively in space will increase the economic value of finding better solutions for getting people into orbit that aren't so fuel hungry and/or dangerous.
Though really, I think the best move was getting that out of NASA's hands. NASA appeared to be becoming an organization that was unwilling to take risks or consider new ideas. And management there appeared more interested in blame shifting and PR than actually solving problems. The Challenger disaster and the unwillingness of management to take any blame for constantly decreasing safety margins in an attempt to make sure all launches happened on time is a case in point.
Ahh, so you spend a dollar on the Apollo program, and then that same dollar on a poverty reduction program? How does that work? Do you counterfeit it or something? Won't that cause inflation?