He's probably referring to the left-hand-side menu containing the template code for buttons, listboxes etc. It's still a stupid remark though. Who cares if you automate some tedious programming stuff - that's the whole point of using the computers in the first place!
I always use Google Sky Map. Aha! Mercury is in the Ascendant on the Whale. Ooh and Neptune is close to Aquarius.
Here's my prediction based on Google Sky Map: avoid water. There is a Whale in your future together with Neptune, God of the Sea. There is also a light (Aquarius, enlightenment) in your future so you will probably light a match to see what's going on after being swallowed. This will explode the whale, killing you.
My advice: stay away from seas and aquariums. Now give me 50 bucks:)
(Yeah I know old school astrologists use a different set of signs. I'm modern though:))
Oh and another thing: there is also the issue of being old enough to give context and meaning to some of the things you see on internet. This way, if the kid asks, you can show things to them and explain the ins and outs (heh) of the matter.
Or were you asking rhetorical questions? In that case the first one is still no. They're more like... friendly adversaries. You try to game them so they approve your app, warts and all. They try to catch as much of your trojans and malware as they can. It's a meta game:)
Assigning the patent to the inventor would be much too risky for Twitter. Because once the inventor died, the patent would be up for sale to the competition if they're unlucky. And you don't want to go into a court room and try to argue "dying means end of employment so we get it" versus the widow arguing "dying means end of contract before end of employment so we get it". Having to depend on race conditions is bad.
And firing the inventor is possible. However, bad publicity will impact them.
I remember a company that 10 years ago decided it would be a good idea to invoke a seldom-used clause to get rid of the benchsitters during a minor IT crisis. They're gone now (due to a "merger") but their remaining employees tell me they *still* hear jokes about it when they show up at a new client. Short term gain, long term they lost the company. Sure they can do that once. But afterwards they will have massive internal issues with the people who actually patent stuff - their smartest people.
And when the company goes bankrupt, not even the written contracts mean anything. All their patents *will* end up as a nice trophy for the highest bidder, who can then do with them whatever he wants.
Did you know that if a company goes under, the curator can re-negotiate ANY licensing deal they ever closed? Including the "eternally free for a thousand years cross my heart" deals? That goes for anything the company released as open-source as well, unless they made escrow arrangements or transferred the IP property to an independent organisation (one reason why Apache is a foundation and not part of the original company any more: too dangerous for serious business use).
The real solution for Twitter would be to set up a foundation (like Apache, or EFF) that held all the patents, with a very well defined charter, that would be chartered not to sell or give them away, and only use them in defense of Twitter. Give them enough money, and they should last at least as long as the patents themselves.
I love Literate Programming in theory. In practice, I find the source code of a Literate program ugly. I'm not sure a WYSIWYG would help. I believe the concept is a good concept, and what holds it back is the lack of a modern realization of the concept that makes the LP easier to follow and easier on the eyes.
True. If I was working for Microsoft Research, I think this would be a nice start for a research proposal. As it is, I can only dream:)
Ratio of CS educated programmers to random people picked off street and cleaned up: 1 to 100.
Yeah I'm making that up, but in the course of my career I've worked with hundreds of developers and I think I've only encountered 1 or 2 CS graduates in my work. I meet more of them socially than I've ever seen in the workplace doing real work (not managing the IT dept.).
I'm not sure that Architecture is just about the non-functional requirements. In my opinion, the Architecture doc is about ALL the constraints on the solution from an implementation point of view, not just the technical constraints.
Your list does make sense though. Perhaps I should reconsider my opinion.
The idea is interesting but the tight coupling makes it difficult to check behaviour, unless you test the output on screen. Perhaps your tests are too granular for that?
I understand, but at least do this: - keep a change log. Even when I'm under extreme pressure I write down at least what the customer wants, and what I'm going to do about it. What did I change where. - keep a decision log. Every time you have to interpret a request or design spec in a certain way, write it down.
I once got hired back to a place I worked for 3 years before that, and had to answer questions about the code I designed when I worked there before... fortunately I always document at least the basics diligently but it still made for some sweaty moments. So yeah, it could be your friend. But it could also be you after 3 or more years:)
Interesting sidestep: consider Literate Programming (http://en.wikipedia.org/wiki/Literate_programming). Donald E. Knuth advocates the approach of document, AND code, then compile the documented code. I have always been fond of this and try to use this in all my programming.
Just comment preconditions, postconditions and mock up the pseudo-code, then extend it.
I'd absolutely love it if Eclipse and Visual Studio supported this. However, most people don't know Literate programming so I doubt it's going to be in there anytime soon.
You need to distinguish between functional and technical specs.
Functional specs are very usefull (if done even halfway right). Technical specs are a waste of time unless you assume by default that you're dealing with incompetents, in which case you're better off saving yourself time, money and aggravation and hire a better developer.
So I do write a lot of functional specs. Even now, in an agile environment, with HUGE time pressure and multi-million penalties for delivering late - just finishing up my final 40 pages (90 pages total, in this 4 week sprint). Why? Because not doing so will make the project much later. Good architecture (system design) specs will make the project about 20% more likely to deliver on time (citation if I can find it again) even if the programmers don't follow the guidelines (interesting, right?). This matches with my experience: if you write decent designs, you are more likely to find the pitfalls before they can bite you in the ass. If you cover all the bases and make sure the business has provided for all scenarios before you get there, your project will run smoother.
So docs may not prevent all the bugs. But it does prevent a large number of nasty stuff before it gets to the stage where it turns into a defect.
It's actually a textbook case. In Austria one company pushed another, very old and established company, right out of the market using this tactic. It's viable, and companies use it. So yes, if Honeywell hasn't applied for branding rights on that, by all means bring out your own thermostat in that shape and do so. You can't do it before you actually establish market presence though. Which would bring the Honeywell patents down upon you. It's a sort of "who shoots first" situation where Honeywell commands the high ground and fully intends to keep it that way.
Slashdot Mirror
I use Onavo. Free and similar.
Also, since I upgraded to Android ICS I've seen more options to control the data from the settings so I recommend people check that out first.
You're just adding insult to injury here :)
He's probably referring to the left-hand-side menu containing the template code for buttons, listboxes etc. It's still a stupid remark though. Who cares if you automate some tedious programming stuff - that's the whole point of using the computers in the first place!
Better use Crashplan (free). Backup to a remote computer, internet or your own disks in the background. Works for me (and lots of other people).
I always use Google Sky Map. Aha! Mercury is in the Ascendant on the Whale. Ooh and Neptune is close to Aquarius.
Here's my prediction based on Google Sky Map: avoid water. There is a Whale in your future together with Neptune, God of the Sea. There is also a light (Aquarius, enlightenment) in your future so you will probably light a match to see what's going on after being swallowed. This will explode the whale, killing you.
My advice: stay away from seas and aquariums. Now give me 50 bucks :)
(Yeah I know old school astrologists use a different set of signs. I'm modern though :))
Oh and another thing: there is also the issue of being old enough to give context and meaning to some of the things you see on internet. This way, if the kid asks, you can show things to them and explain the ins and outs (heh) of the matter.
You're not the one who has to deal with your kid waking up screaming in the middle of the night for a week, I can tell.
While it may not scar him for life, there are things I don't want him to see for my own comfort. I like a good night's sleep.
I guess the mandatory condom with lube helps a bit there as well.
No. Yes. Yes.
Or were you asking rhetorical questions? In that case the first one is still no. They're more like... friendly adversaries. You try to game them so they approve your app, warts and all. They try to catch as much of your trojans and malware as they can. It's a meta game :)
That could work, but only if the curator allows it. It's a pretty risky strategy.
I second that. It is.
Assigning the patent to the inventor would be much too risky for Twitter. Because once the inventor died, the patent would be up for sale to the competition if they're unlucky. And you don't want to go into a court room and try to argue "dying means end of employment so we get it" versus the widow arguing "dying means end of contract before end of employment so we get it". Having to depend on race conditions is bad.
And firing the inventor is possible. However, bad publicity will impact them.
I remember a company that 10 years ago decided it would be a good idea to invoke a seldom-used clause to get rid of the benchsitters during a minor IT crisis. They're gone now (due to a "merger") but their remaining employees tell me they *still* hear jokes about it when they show up at a new client. Short term gain, long term they lost the company. Sure they can do that once. But afterwards they will have massive internal issues with the people who actually patent stuff - their smartest people.
And when the company goes bankrupt, not even the written contracts mean anything. All their patents *will* end up as a nice trophy for the highest bidder, who can then do with them whatever he wants.
Did you know that if a company goes under, the curator can re-negotiate ANY licensing deal they ever closed? Including the "eternally free for a thousand years cross my heart" deals? That goes for anything the company released as open-source as well, unless they made escrow arrangements or transferred the IP property to an independent organisation (one reason why Apache is a foundation and not part of the original company any more: too dangerous for serious business use).
The real solution for Twitter would be to set up a foundation (like Apache, or EFF) that held all the patents, with a very well defined charter, that would be chartered not to sell or give them away, and only use them in defense of Twitter. Give them enough money, and they should last at least as long as the patents themselves.
I love Literate Programming in theory. In practice, I find the source code of a Literate program ugly. I'm not sure a WYSIWYG would help. I believe the concept is a good concept, and what holds it back is the lack of a modern realization of the concept that makes the LP easier to follow and easier on the eyes.
True. If I was working for Microsoft Research, I think this would be a nice start for a research proposal. As it is, I can only dream :)
Ratio of CS educated programmers to random people picked off street and cleaned up: 1 to 100.
Yeah I'm making that up, but in the course of my career I've worked with hundreds of developers and I think I've only encountered 1 or 2 CS graduates in my work. I meet more of them socially than I've ever seen in the workplace doing real work (not managing the IT dept.).
So 1:100 might be an optimistic estimate.
I'm not sure that Architecture is just about the non-functional requirements. In my opinion, the Architecture doc is about ALL the constraints on the solution from an implementation point of view, not just the technical constraints.
Your list does make sense though. Perhaps I should reconsider my opinion.
The idea is interesting but the tight coupling makes it difficult to check behaviour, unless you test the output on screen. Perhaps your tests are too granular for that?
Good practice. I use it too and it works great for me as well.
I understand, but at least do this:
- keep a change log. Even when I'm under extreme pressure I write down at least what the customer wants, and what I'm going to do about it. What did I change where.
- keep a decision log. Every time you have to interpret a request or design spec in a certain way, write it down.
Over time, these will keep you afloat.
You're right. Knuth is still much more advanced than this writer.
I once got hired back to a place I worked for 3 years before that, and had to answer questions about the code I designed when I worked there before... fortunately I always document at least the basics diligently but it still made for some sweaty moments. So yeah, it could be your friend. But it could also be you after 3 or more years :)
Interesting sidestep: consider Literate Programming (http://en.wikipedia.org/wiki/Literate_programming). Donald E. Knuth advocates the approach of document, AND code, then compile the documented code. I have always been fond of this and try to use this in all my programming.
Just comment preconditions, postconditions and mock up the pseudo-code, then extend it.
I'd absolutely love it if Eclipse and Visual Studio supported this. However, most people don't know Literate programming so I doubt it's going to be in there anytime soon.
You need to distinguish between functional and technical specs.
Functional specs are very usefull (if done even halfway right). Technical specs are a waste of time unless you assume by default that you're dealing with incompetents, in which case you're better off saving yourself time, money and aggravation and hire a better developer.
So I do write a lot of functional specs. Even now, in an agile environment, with HUGE time pressure and multi-million penalties for delivering late - just finishing up my final 40 pages (90 pages total, in this 4 week sprint). Why? Because not doing so will make the project much later. Good architecture (system design) specs will make the project about 20% more likely to deliver on time (citation if I can find it again) even if the programmers don't follow the guidelines (interesting, right?). This matches with my experience: if you write decent designs, you are more likely to find the pitfalls before they can bite you in the ass. If you cover all the bases and make sure the business has provided for all scenarios before you get there, your project will run smoother.
So docs may not prevent all the bugs. But it does prevent a large number of nasty stuff before it gets to the stage where it turns into a defect.
So if it happened to you, you'd be dancing in the street, overflowing with joy? Somehow I doubt it.
It's actually a textbook case. In Austria one company pushed another, very old and established company, right out of the market using this tactic. It's viable, and companies use it. So yes, if Honeywell hasn't applied for branding rights on that, by all means bring out your own thermostat in that shape and do so. You can't do it before you actually establish market presence though. Which would bring the Honeywell patents down upon you. It's a sort of "who shoots first" situation where Honeywell commands the high ground and fully intends to keep it that way.