That's interesting because I've seen the exact opposite.
When I am rolling an internal app I can sit down with management and the requestors and explain clearly exactly how much time and resources will be needed. I can also suggest better options and usually a compromise is reached where they get 85% of the functionality they want, 100% of the functionality they *need* and it takes me 15% of the time the original request would have.
Comparing that to the attitudes (of others) of vendor software, we're paying them for the software AND support so they'd better damn well bow to our every whim. That usually results in us getting about 0% of what we needed, wasting a lot of time trying to get it and everyone hating the vendor software even more than they did before.
Not to mention that the vendor software rarely if ever works out of the box, as it wasn't tested by us first. Homegrown apps *always* work when they're given the official release because they were tested by exactly the crowd that is going to be using it (as well as those who wrote it).
You clearly either don't want to understand what I'm saying or don't care to... but I'm going to spell it out for the benefit of others anyways:
Most software exists for somewhere between 5 and 10 years. In some cases the product line or even the name will continue but undergo a major overhaul that renders it essentially a new product.
A well paid and respected employee tends to stay with a company for 20 years or more. If you have that kind of turn around (you say half over 3 years) your company clearly does not adequately pay or respect it's employees.
There is absolutely no justification for support contracts or outsourcing when the upfront cost and continued support contracts cost more than the price of the development effort to create what you need in the first place. General purpose databases, web servers, productivity tools and operating systems to name a few; they are so used in business that outsource cost is very low and rolling your own is (generally) futile.
When people reference nothing but hardware you know they have no fucking clue about enterprise or the industry in general.
I can count on one hand the number of man-hours spent on switches in a year. There are days when I can't count on both hands and feet the number of man-hours wasted on a buggy vendor-provided API.
So long as the when isn't possibly, I agree; however I also acknowledge that my position is not everyones.
If an employer want's me to put in 8 hours of logged activity on a computer they provide at any time during a 24 hour day, perfect.
However the only reason that I prefer to work from home is the flexibility of time; so long as I am not in meetings it makes no difference when I do the work so long as it's done.
I however work for an employer that recognizes that it is the quality and amount of work, not how many hours you spend at a desk, that is the valid and important metric.
I am assuming that any company so paranoid that they're logging everything the employee is doing would be equally as batshit crazy about unexplained lulls in activity.
I'm very suspicious about the "cannot be gamed" thing... it's software, ffs.
I can't believe I'd never considered this... you sir win my fucking genius idea of the day award.
As you said that I realized that the apple BT keyboard I'm using at the moment has a nice cylindrical battery compartment that I might even be able to hack a shake-to-charge flashlight system into. I wonder if it'd hold enough charge.
Well it's a completely valid point but it doesn't quite cover the whole scope of the SETI project. I don't imagine SETI actually has a lot of faith that they can see *current* communications between anyone; for one thing we just can't... unless they were in one of the very few close systems.
Keep in mind that even if every intelligent civilization other than us evolved millions of years ahead of us at the same time (the hardest possible thing to detect, I suspect). We've got systems at differing distances offering looks into different points in their pasts.
So if you assume* that every evolving race went through a similar phase that we're in now (pumping massive amounts of patterned EM off the planet) There should be *something* to detect *somewhere*. So then if you tasked G. Washington with surveying a ton of huts at different stages in their evolution you can bet that one of them would have tracks going back and forth (he doesn't need to see a messenger, just proof that there was one).
The issue then becomes that for all we know it could be a tiny sliver of their history (we're getting close to being able to broadcast/receive below radiation floor at which point we disappear to others) and there are billions of planets to look at.
*Of course I do realize that making such assumptions about alien development is already a bit of a laugh; It's not completely unreasonable though.
Did you miss the part where very carefully crafted pre-commit hooks test each batch before it becomes a revision, and only ones that compile and pass all unit testing are deployed?
Yes, you did because you're a fucking moron.
I'm done replying to you now, you may pass my sympathy along to your employer.
Yeah, see that's what I thought. You don't have a single, not even one, argument; You're just being dense. Our repositories are the cleanest and most useable of any anyone here has ever worked with. Clutter is what most svn repos are; meaningless update paths from each developers mind with no proper tagging or logic.
Luckily, I'll never have the misfortune of working with you since you clearly wouldn't even make it past our application process... let alone an interview.
Give me one *1* example of how using versioning to... you know... version files makes anyone's life harder?
My entire team is anxiously awaiting a response to that question since no one is able to provide it as of yet.
Preventing clutter in the repository? if that's your concern you shouldn't be using one in the first place... All those old files that clearly don't matter anymore.
Keeping everything in an ordered and useful fashion makes all of our lives easier; we'd all love an explanation as to how having less data with less organization is supposed to be "simple"
I read your other post, and you seem to have the same problem as dingen.
Versioning systems are designed for versioning. Anything you attach above and beyond that is your baggage, not mine.
There is simply no valid case for hooks and tags if your vision of version control were the right one. You would know about these things if you had any real experience working with a team in a (useful) business setting.
If you want to use versioning in a very naive way, only making use of a very small set of it's functions that's your business; it doesn't make it any better an idea.
The point of a versioning system is to store versions.
Anything you add above that is purely your own, You have yet to provide me with any compelling reason for your belief, while I have pointed to several reasons for mine.
I have used others, svn works quite well and is from my experience the most widely known.
I'm unclear as to your objection to non-working commits... I honestly can't even imagine why you would bother using a *shared* versioning system if you only ever commit fully functional code.
If the only reason you ever want versioning is for backup purposes, then it should be done in the same location as your testing (locally in your case).
Seriously, I would love for you to detail your idea of why svn/development servers/etc exist if everyone always puts forth perfect code...
Well for one thing, if I only ever check in working code how do I access it when I'm on the road? A separate repository for me personally? scp it to a server somewhere? very kludgy.
Portability. I have no end of trouble using a laptop (netbooks are slightly better, but most of the trouble comes from the angle of my wrists) on trains/planes/some conference seating.
Now that's not to say I'm doing dev work in all of those settings all the time, but I have found that I can more easily position just a keyboard than a full laptop. Keyboard with a laptop would work, but that's going to take up a lot of space.
Actually the data plans for the ipad are cheaper (here) than the equivalent netbook plans. I like that you're somehow getting free internet on the netbook though, that's cool.
You're also getting reduced screen space on the netbook, a smaller less useful keyboard, etc. etc.
Slashdot Mirror
That's interesting because I've seen the exact opposite.
When I am rolling an internal app I can sit down with management and the requestors and explain clearly exactly how much time and resources will be needed. I can also suggest better options and usually a compromise is reached where they get 85% of the functionality they want, 100% of the functionality they *need* and it takes me 15% of the time the original request would have.
Comparing that to the attitudes (of others) of vendor software, we're paying them for the software AND support so they'd better damn well bow to our every whim. That usually results in us getting about 0% of what we needed, wasting a lot of time trying to get it and everyone hating the vendor software even more than they did before.
Not to mention that the vendor software rarely if ever works out of the box, as it wasn't tested by us first. Homegrown apps *always* work when they're given the official release because they were tested by exactly the crowd that is going to be using it (as well as those who wrote it).
You clearly either don't want to understand what I'm saying or don't care to... but I'm going to spell it out for the benefit of others anyways:
Most software exists for somewhere between 5 and 10 years. In some cases the product line or even the name will continue but undergo a major overhaul that renders it essentially a new product.
A well paid and respected employee tends to stay with a company for 20 years or more. If you have that kind of turn around (you say half over 3 years) your company clearly does not adequately pay or respect it's employees.
There is absolutely no justification for support contracts or outsourcing when the upfront cost and continued support contracts cost more than the price of the development effort to create what you need in the first place. General purpose databases, web servers, productivity tools and operating systems to name a few; they are so used in business that outsource cost is very low and rolling your own is (generally) futile.
When people reference nothing but hardware you know they have no fucking clue about enterprise or the industry in general.
I can count on one hand the number of man-hours spent on switches in a year. There are days when I can't count on both hands and feet the number of man-hours wasted on a buggy vendor-provided API.
The job length of a well paid and respected employee is far longer than your typical product life cycle.
Clearly the war on drugs is very successful and victory is immanent.
In fairness I did say "unexplained".
I would think you'd have a hard time finding valid excuses for habitual slacking off.
So long as the when isn't possibly, I agree; however I also acknowledge that my position is not everyones.
If an employer want's me to put in 8 hours of logged activity on a computer they provide at any time during a 24 hour day, perfect.
However the only reason that I prefer to work from home is the flexibility of time; so long as I am not in meetings it makes no difference when I do the work so long as it's done.
I however work for an employer that recognizes that it is the quality and amount of work, not how many hours you spend at a desk, that is the valid and important metric.
I am assuming that any company so paranoid that they're logging everything the employee is doing would be equally as batshit crazy about unexplained lulls in activity.
I'm very suspicious about the "cannot be gamed" thing... it's software, ffs.
Took me just a second, but I did chuckle heartily :)
I can't believe I'd never considered this... you sir win my fucking genius idea of the day award.
As you said that I realized that the apple BT keyboard I'm using at the moment has a nice cylindrical battery compartment that I might even be able to hack a shake-to-charge flashlight system into. I wonder if it'd hold enough charge.
Well it's a completely valid point but it doesn't quite cover the whole scope of the SETI project. I don't imagine SETI actually has a lot of faith that they can see *current* communications between anyone; for one thing we just can't... unless they were in one of the very few close systems.
Keep in mind that even if every intelligent civilization other than us evolved millions of years ahead of us at the same time (the hardest possible thing to detect, I suspect). We've got systems at differing distances offering looks into different points in their pasts.
So if you assume* that every evolving race went through a similar phase that we're in now (pumping massive amounts of patterned EM off the planet) There should be *something* to detect *somewhere*. So then if you tasked G. Washington with surveying a ton of huts at different stages in their evolution you can bet that one of them would have tracks going back and forth (he doesn't need to see a messenger, just proof that there was one).
The issue then becomes that for all we know it could be a tiny sliver of their history (we're getting close to being able to broadcast/receive below radiation floor at which point we disappear to others) and there are billions of planets to look at.
*Of course I do realize that making such assumptions about alien development is already a bit of a laugh; It's not completely unreasonable though.
Well as luck would have it monitoring *one* planet is very reasonable and not overly resource intensive.
SETI's problem was always that they tried to monitor a *lot* of planet/star/whateverthefucks
Wow, you're even fucking dumber than I thought...
Did you miss the part where very carefully crafted pre-commit hooks test each batch before it becomes a revision, and only ones that compile and pass all unit testing are deployed?
Yes, you did because you're a fucking moron.
I'm done replying to you now, you may pass my sympathy along to your employer.
Yeah, see that's what I thought. You don't have a single, not even one, argument; You're just being dense. Our repositories are the cleanest and most useable of any anyone here has ever worked with. Clutter is what most svn repos are; meaningless update paths from each developers mind with no proper tagging or logic.
Luckily, I'll never have the misfortune of working with you since you clearly wouldn't even make it past our application process... let alone an interview.
Okay, let's try this then:
Give me one *1* example of how using versioning to... you know... version files makes anyone's life harder?
My entire team is anxiously awaiting a response to that question since no one is able to provide it as of yet.
Preventing clutter in the repository? if that's your concern you shouldn't be using one in the first place... All those old files that clearly don't matter anymore.
Keeping everything in an ordered and useful fashion makes all of our lives easier; we'd all love an explanation as to how having less data with less organization is supposed to be "simple"
You need to either lie better, or not at all.
You are wrong, and you would know it if you ever had any of the experience you claim to outside of gaming websites.
With that said, you're welcome to be wrong; just don't tell other more experienced and intelligent people that they are.
I read your other post, and you seem to have the same problem as dingen.
Versioning systems are designed for versioning. Anything you attach above and beyond that is your baggage, not mine.
There is simply no valid case for hooks and tags if your vision of version control were the right one. You would know about these things if you had any real experience working with a team in a (useful) business setting.
If you want to use versioning in a very naive way, only making use of a very small set of it's functions that's your business; it doesn't make it any better an idea.
The point of a versioning system is to store versions.
Anything you add above that is purely your own, You have yet to provide me with any compelling reason for your belief, while I have pointed to several reasons for mine.
I have used others, svn works quite well and is from my experience the most widely known.
I'm unclear as to your objection to non-working commits... I honestly can't even imagine why you would bother using a *shared* versioning system if you only ever commit fully functional code.
If the only reason you ever want versioning is for backup purposes, then it should be done in the same location as your testing (locally in your case).
Seriously, I would love for you to detail your idea of why svn/development servers/etc exist if everyone always puts forth perfect code...
Well for one thing, if I only ever check in working code how do I access it when I'm on the road? A separate repository for me personally? scp it to a server somewhere? very kludgy.
Portability. I have no end of trouble using a laptop (netbooks are slightly better, but most of the trouble comes from the angle of my wrists) on trains/planes/some conference seating.
Now that's not to say I'm doing dev work in all of those settings all the time, but I have found that I can more easily position just a keyboard than a full laptop. Keyboard with a laptop would work, but that's going to take up a lot of space.
Never used tags?
it's very clear up front what revisions do and don't work.
If everything were tested locally and there was no need for testing on the server, why would you have a development server in the first place?
If everything needs to be tested on the server, why bother testing locally?
IDE does not equal interface design software. In some cases they are combined in one bundle, in some they aren't.
I have no use for IDEs, I do have use for interface design software.
But keep digging, you'll see light eventually.
Actually the data plans for the ipad are cheaper (here) than the equivalent netbook plans. I like that you're somehow getting free internet on the netbook though, that's cool.
You're also getting reduced screen space on the netbook, a smaller less useful keyboard, etc. etc.