Here is my strategy for dealing with this situation:
1) Tell the salesmen that you have absolutely no problem with them telling the customer whatever they want. Their function is to make sales to customers. Your function is to write software. You won't try to tell them how to do their job, because quite frankly you aren't qualified to know what's best for sales. Of course the implication is that they shouldn't tell you how to write software, but you probably don't have to tell them this explicitly (well, it happened once that I had to say it...)
2) Show the salesman what you actually *are* going to deliver. Generally a list of use-oriented functionality is the best. You might be doing a lot of refactoring underneath, but they won't understand that. Only list what the user will see.
3) Probably what they are saying to the customer and what you are promising to deliver will not match. No matter how clueless they are, the salesmen will probably notice and tell you, "You had better do something to fix the situation". This is where you reiterate, "I can't tell you what to say to the customers, that's up to you. But this is what I plan to release. However, if you would like to substitute something on this list with something more important, I'd be happy to oblige."
4) Now they will still want it all. They will tell you that the whole company will go under unless you deliver everything. You can now say, "That's a shame. I like working here too. Well, if that's the way it is, I guess I'll go fix up my resume. It was great working with you." You only have to do this once (thank god). At this point the salespeople will say, "Well, maybe we can do something if you at least give us feature X".
5) Negotiate with the salespeople. But use each piece of functionality as a lego block. Its size is immutable, but you can put it in, take it out, put it in a different place etc. At every point make sure to point out that you are quite happy to allow the salesmen to choose what they want you to do. It's just that it doesn't all fit.
6) Sometimes you will run into the situation where the salesman will swear at you and tell you to go do something anatomically impossible. Then they will storm off. At this point it's important to let them go, but to go to your own management (or executive management if you have no manager) and explain, "The salesmen are upset and I understand their point of view. They can't have everything that they want. It's frustrating for me too. But I need them to choose what things are most important. If you could just have a chat with them so I can prioritize things properly I would really appreciate it." After this you will have no problems (unless the salesman in question *is* executive management, in which case you should jump ship as quickly as possible).
7) Probably you will have to go through this charade about 4 or 5 times. But each time it will get easier. There will be one last time where they will pull every dirty trick in the book. Just hang tough, because after that you will have no problems.
Git an Mercurial are fundamentally different from the others you mentioned. They are distributed version control systems. You are free to set up your own topologies and methods for synchronizing. The biggest disadvantage is in not being able to easily checkout partial trees. This affects your workflow. IMHO, it results in a better workflow since you are forced to decouple the release of separate projects. But I'm sure I would get some stiff arguments from some people on that point. (My main argument is that if the release is coupled, then everyone *needs* to have an updated version of the project. If they don't need to have an updated version of the project, then you should be thinking seriously about what version they *do* need)
Anyway, you may or may not like this way of doing things since it is quite different from what you are used to. But it's worth your time to check it out.
This is a stupid "me too" post, but hopefully it will lend credence to what you say.
I originally used SVN because at the time there weren't any other credible options. I moved to bzr because I wanted distributed version control and bzr's syntax seemed easier than Git. Now I'm in the processes of moving over to Git. Git's documentation has vastly improved and that's a big reason for my change. I can't even really understand why I thought it was more difficult than bzr now. I also think that if people tried Git they would find it easier to use than SVN in almost every circumstance (there are a few counter examples, however).
The SHA1 hashes may look scary at first, but it really is the best approach. Incremental revision numbers are meaningless because there's no way to determine the order of the revisions on the distributed branches. For important revisions on a public repository you can always use a tag.
Like you, one of the main features of Git is that I can understand what it's doing all the time and why it's doing it. Again, kudos to the people who improved the documentation, but a lot of this is also just good design.
I don't think you have to justify your use of a proprietary driver at all. You are, in fact, using a proprietary driver *in order run a proprietary piece of software*. It would rather stupid for someone to say that you should choose freedom in one case and not in the other.
I'm a huge fan of free software. From a user's perspective it is just better. When stuff doesn't work I can move to another vendor without losing the software I've grown used to. This is a massive advantage for me. Without software freedom I get locked into a single vendor who generally doesn't care about me. Having worked for proprietary software vendors for nearly half of my life, I understand all too well what their attitude is towards end users (can you say, "cost center"?) Free software forces vendors to place their customers well being first (otherwise they can, and will, walk to someone else).
I don't think anyone wants to deny you the right to run whatever software you choose (as long as you abide by the license agreement, and as long as you don't choose a platform with DRM that restricts what software you can run on it). Choosing proprietary software is unfortunate, though. I can understand why you do, if you have no choice. But choosing free software not only has the potential to help you, it can also help others. Free software projects thrive on use (even if the users don't pay money). So when you have the choice it would be great if you can try to use free software.
The last one got me pretty bad. The absolutely best thing I've found is running. The endorphins really help a lot. You may have to work up to it, though. If you're not already a runner then running for about 10 minutes a day and increasing slowly up to 30 minutes over a 2 month schedule is probably OK. Check out some beginning running web sites. Running in the morning is good because you'll feel better at the start of the day.
Also, give yourself time to recover. Getting dumped is just like any other injury; it takes time to heal. I gave myself 3 months, after which I said "Fuck it" and moved on. I also casually dated a lot over that time, but go at your own speed. Whatever works best for you.
Only marginally related but... I remember playing a rogue style game (who's name I forget) with huge maps. But the save file was tiny. I couldn't figure out how they did it until I looked at the source code. They generated the maps pseudo-randomly and saved the seed for the random number generator in the save file. As long as the maps were regenerated in the same order you would always end up with the same map. Not exactly compression, but it's a useful technique for avoiding saving pseudo-random information.
If you were a diabetic and we could find a cure for diabetes or give you a drug that removed all symptoms, which would you prefer?
Making you a slave to a drug is not the same as a cure. Making someone thin does not make them healthy. Even if you burn all the calories you eat, eating a high fat diet can kill you, for instance.
Does it mean that a drug would not be useful in some situations? No. But assuming that controlling symptoms removes the problem is a dangerous way to look at the world.
I'm not worried about X breakages, personally. I even have an Intel 945G and I can live with the problems its causing. What I can't live with is the extreme instability of Pulse Audio. It crashes my apps contstantly from broken pipes. OK, people should be checking their pipes. But Pulse Audio itself crashes very frequently (about every hour or so on my machine). Rhythmbox won't go for more than 10 minutes without either crashing or audio failing. This is incredibly bad for me.
I realize that it's probably due to older, underpowered hardware (3 year old cheap laptop), but this should not be happening. I've yanked Pulse Audio from my machine altogether now and it's a lot more stable. I was also getting lock ups in Firefox every hour or so. Now that I've dumped Pulse Audio, I've only had one lock up in the past 3 days (still can't figure that one out -- related to video drivers???).
So, I plead with Ubuntu developers: either fix Pulse Audio, or punt it. The extra features it has is *not* worth the massive pain that some people experience.
I've worked on some flops in my time too. At subsequent interviews I'm pretty candid about what went wrong. For example on one project it became clear that we were building a product that nobody would want to use. Eventually the project was canned because it was simply stupid. I'm invariably asked what I would do differently in those situations.
I respond that when I see a potential problem, I discuss it with my manager. I point out possible solutions and indicate the cost of remedial action. I try to explain what the consequences of ignoring the problem is. Usually they ask if that will solve the problem. I say, probably not. Because I am not running the project. I am only one voice and can only view the project from my perspective. I will honestly give feedback and and discretely point out potential problems. But business is about taking risk. I may not be able to fully understand the risks and potential benefits from my position. So in the end I will discuss problems, but I will accept decisions and do my best to fulfill my role. Sometimes the risk doesn't pan out and we are left with a failure. Even if I correctly predicted the failure, that doesn't mean it wasn't worth trying.
If the we developed a drug that allowed people to be thin while eating whatever they want, would that really help people who over eat? Surely this is treating just the symptom. They are still addicted.
Like you, I reject the idea that "will power" will help obese people improve their life. Changing your self is hard. You have to want to do it. You have to be able to imagine yourself as the person without the thing you are addicted to. And you have to be happy with that. Once you do that, will power is not an issue one way or another.
Helping people get thin does nothing to help them with their addiction.
Please re-read the book. I wish I had it here (my copy is about 5000 miles away at the moment), but I think what you just wrote is already there. A design pattern, by definition, is something that is intuitively used by many people, whether they know what it's called or not. IIRC you can't call it a pattern unless there are 3 independent implementations of it. So one of the biggest pluses for design patterns is in being able to recognize them in existing code and thereby understand it more easily.
The next thing to realize about design patterns is that they are supposed to be generative. In other words, the use of one pattern naturally leads to the use of another. In other words, it generates the need for that pattern. One of the best uses of design patterns is in refactoring. Quite often you'll look at the design and say, "OK, we've got a state pattern here. And the way it's shaped, we probably need command pattern.... Hey, where's the command pattern in this code? Oh... OK, so that's what's causing the problems."
I am in complete agreement with you that using design patterns as some sort of list of ingredients in a recipe will almost certainly lead to disaster. And I'm relatively sure that this is stated in the GoF book (first couple of chapters... but I admit it's been a long time since I read it). Unfortunately many people try to skip thinking and don't realize that the random use of patterns won't actually make their code any better.
If you look at the early accomplishments of the people in the GoF you will see that they were well ahead of the curve when it comes to understanding these subtleties. So I'm quite sure these issues were well understood, although perhaps they could have been communicated better.
I never really did Scrum, but on several XP teams we had daily standups in the morning. However, I *never* invited the manager. In fact, I explicitly told the manager he wasn't welcome. A standup is about communicating small important issues to the rest of the team so that they don't have to discover it themselves. For instance, "I've changed the interface to this class, so if you're going to use it, please come and talk to me." It should never, ever be about tracking progress!!!!!! In XP there is an iteration plan, in Scrum there's a backlog. Either way that document tracks progress. A manager should never, ever ask "How far are you in your task", or "Do you think you'll finish in time" or "What have you done". He can look at the plan to see what is crossed off the list (and if you're really on the ball you've got people independently verifying that the acceptance tests are acceptable). It's up to *you* to warn people if you think your task won't fit in the time remaining. Everything else can be determined by looking at the plan/backlog.
Agile should be *easy* on you from this perspective. It's one of the reasons it's called agile. If you're not finding it this way you're doing it wrong (IMHO -- of course flame wars have been started on less). Ideally you should never talk to your manager. All information up and down the chain should be transparent. This leaves your manager free to act solely as a shit shield. Unfortunately most managers are too micro-managing to do agile properly.
Wow, lots of replies, but very few that are useful. Unfortunately I'm probably too late to get this modded up, but let's try...
First and foremost you need to realize that "getting a boy/girlfriend" is not like getting a pizza. It's not like an achievement in WoW. It's not a goal. If you treat it as such, you will be all uptight, needy and hopeless. It is simply choosing to spend time with someone and having them choose to spend time with you. It's simple, natural and normal.
If it's so simple and natural and normal, why are there some people for whom it seems impossible? First, let me reassure you: You aren't a freak if you don't have a GF/BF. Well, you might be a freak anyway, but freakiness doesn't necessarily rule out getting a partner. The reason you are single is because you have chosen (probably unconsciously) to be single. You aren't willing to accept what you need to do/be in order to get a partner.
First thing you need to do: learn from Fenyman. He said that the secret to sleeping with girls is (wait for it)... asking them. That's right. You need to be upfront and OK with your desire to have a partner. You need to have courage. When the opportunity arises to create a romance with someone (who you probably just met), then you have to take it. Don't think about it. Don't hesitate. Just do it.
I know. You have all sorts of excuses about why you can't do that. You're shy. You're fat. You're ugly. You've been turned down too many times before. You don't want to scare the person off. None of that matters now. You must be absolutely insensitive to those things. Turn your brain off and go with your hormones. If it's being offered, take what you want. And don't under any circumstances start thinking, "Well, maybe I shouldn't because I don't know if it's really best for the other person"!!!!
This leads me to my next point. You are a jerk. You probably don't know it, though. You probably think you are a nice guy/nice girl. Well, you aren't. You're a jerk. Nice people are open and honest enough with their feelings to reach out to someone. You always hold back. You always underestimate the other person. You never let them take responsibility for themselves. The so-called jerks that you think about (the ones who are successful dating and have a million friends/lovers)... they are nice guys/girls. Study them.
I'm not saying that you have to treat people badly (quite the opposite). Definitely a lot of these people are selfish and self-centered. They can be idiotic. They can be mean. But in terms of making friends and lovers, they are nice people. You must learn from them. Get to know them. Admire the things that are good and emulate them. Probably this means taking a huge ego hit and accepting the jocks and low-brow people into your circle of friends.
Which leads me to my next point. Dating is fun. Making friends is fun. Partying is fun. If you aren't having fun, probably you are letting unimportant things bother you. You need to be confident. When one of your new jock friends puts you down, laugh and tell him to stick it where the sun don't shine. But don't let it bug you, even one little bit. Probably you'll have to practice having people insult you for a while until you don't take it seriously any more. Then you can laugh and party with the best of them.
In the dating scene, you will often find yourself in awkward or difficult situations. Being able to laugh and have a good time even when the world is falling to pieces is incredibly sexy. Check out the current Dr. Who to understand the attitude you need. Don't take shit from anyone, but also don't let unimportant things bug you. Just have fun!!!!
Those are the important things. There's one last thing. Respect yourself. Respect means thinking you are important enough to worry about. If you don't think so, then nobody else will either. If you are fat, get thin. If you are unhealthy due to lack of exercise, exercise. If you have bad breath, bad teeth, b
I wish I could answer this question. Then maybe I could figure out why it doesn't work for me. Pulse audio crashes on me constantly (mean time between crashes is about 1 hour). Not only that, but under load applications trying to write to pulse audio will fail and will never again be able to play sound (or more likely crash, actually...). If I am doing anything on my computer and trying to use rhythmbox at the same time things will be crashing every 5 to 10 minutes.
I *do* have an older and lower spec laptop, though. I suspect that's part of my problem. I've also got an Intel 945GM graphics card and I'm using the work-arounds to get decent video performance with compiz, but that's resulted in a horrible memory leak in compiz (I don't blame compiz, though -- I'm pretty sure it's the video driver). So I'm often running in low memory conditions. This causes latency with PulseAudio, I think, contributing to the problems.
But it's no joke... when I upgraded to Jaunty pretty much *everything* broke:-( How hard is it to downgrade again?
Sure we could. But I don't trust you, so I'm gonna have to ask you to drop the gun first. Once you do that, I'll drop my own, too... I promise! Honest!
OK.
When a soldier joins an army it is often said that they join to protect their beliefs and way of life. They are willing to die for those ideals. An army of peace may not fight, but many may die. I would join such an army, even if I die because I believe in peace and it is integral to my way of life. This is not my idea, but I still believe it.
I was around then. My parents had a Betamax VCR. It was *definitely* better than my friend's VHS. But within a very short time you couldn't rent movies on Beta. When I bought my first VCR it was VHS simply for that reason. My parents still had the Beta for years and years afterwards. If I wanted to tape something I often did it at my parent's place because the quality was noticeably better.
Now I can't comment on exactly caused VHS to win, but that was my experience.
Lots of good replies here, so I won't touch on whether or not code reviews are beneficial. But one thing jumps out at me from the question:
"I'm a development manager... I asked my boss to consider whether it was worth spending so much time on examining built code..."
I hate to say it, but you are the wrong people to be considering this question. Code reviews are for programmers. It's good to hear that your reviews are developer led, but you've got some serious problems if you are trying to make this decision on your own. In fact, I'd go so far as to say that you have serious problems if you are attempting to make this decision at all.
Certainly, a development manager's role will involve some coaching (unless you hire a senior developer whose job is specifically geared to coaching the developers -- something I highly recommend). In that coaching role, you could of course guide inexperienced developers towards practices that work well for the team. But at some point practices should be self-selected. The developers can see much better than you can what is worth doing and what isn't.
It's appropriate to gather metrics and ask question about what is effective and what isn't. It can be a launching point for good discussion. But if your opinion of your developers is so low that you think you should make this decision, then you've got problems. Either you need to replace your developers or (more likely) get an attitude adjustment.
He's not being misleading, he's just not telling you everything. They are distributing the library without an attached patent license. *They* have a patent license for the library. The question is whether or not distribution requires the patent license.
The heart of the issue is whether or not the functionality is used in the redistribution. I'm quite certain his take is that it isn't. The *running* of the application is what uses the functionality. Thus the user requires a license, not the distributor. Google is redistributing the library, but clearly they intend it to be "as is" without a patent license. If the user feels they need a patent license then they need to get one.
This is a weakness of V2.1 of the LGPL. Contrast the wording in V2.1 with that in V3 (section 11) and you can see what's causing the problem. In V3 you have the clarification, ""Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid." In other words it relies on the patent if the *user's* use of the software requires the patent.
Basically Google are covering their ass and simultaneously going against the spirit of the LGPL. But they are probably in the clear legally. Personally I think they are being weasels.
This is right on, for programming jobs, anyway. I can tell you that while a masters might get your resume through HR (along with 150 others), it isn't going to mean squat to the people *actually* hiring you. I've hired many, many people and not once did I even think about a masters degree. The only hiring managers I knew who favored people with masters degrees were absolute twits (and there weren't even very many of them).
Another thing to keep in mind -- 2 years of academics is 2 years of not getting paid. It takes a pretty big salary differential to overcome that loss.
While this is an informative post, modding it insightful is a bit trollish. If your definition of "free" means "less restricted", then it is certainly true. If your definition of "free" refers to the "free" as commonly used in "free software", then the statement is meaningless. Either it is free (gives me the 4 freedoms) or it isn't. There isn't "more" or "less".
By saying it is "more free than the GPL" you are making a distinction which is completely unnecessary in this context. The Apache license is both free as in "has few restrictions" and free as in "free software". So you can merely say that the Apache license is a "free license" as opposed to Microsoft's "shared source" licenses.
I, for one, am getting tired of these pointless political jabs.
What makes you think open-source drivers automatically makes them suck less?
There are some people (I am included in that group) for whom non-free software carries a certain minimum suckage, so to speak. It is true that if I have no alternative, I will use non-free software. But if I can do what I need to do I'll pick free software even if the alternative has more functionality. I'll save the rant about the value of freedom for the end user for another time. But I place a very high value on that freedom.
For example, I have an Intel 945GM card in my laptop. The 3D drivers in Linux suck very badly (sorry if anyone working on it is insulted), performance wise. Basically, I can play no games on it. My $50 NVidia graphics card *from 5 years ago* has 2 or 3 times the performance. But, if I were really worried about it, I could do something. The reason I moved from the NVidia card was a bug in the proprietary driver several years ago that caused me not to be able to do my work for some time (forget off hand the details). I felt powerless to do anything. And, for me, that sucked far more than the crappy 3D performance on my Intel card.
Just because it's open source doesn't mean it doesn't suck. The Intel drivers have always had serious performance problems. Now this. I wish there was someplace else to turn. On the other hand the binary blobs suck precisely because they are binary blobs.
What this rant needs is: "I should get off my butt and fix the damn Intel drivers".
Yeah, I have to agree with this. I'm living in Shizuoka prefecture in Japan and it gets "Florida hot" and then some (I lived in Tallahassee for a year when I was a kid). In the school where I work we *do* have air conditioning. It's set at 28 degrees C. I don't have air conditioning in my house. I use a hand fan during the day and an electric fan at night. If it's really hot I wear a wet bandana on my head. You get used to the heat. Hell, it's barely even warm here compared to places like India.
Definitely not true. There used to be a bug somewhere in the CIBC (Canadian Imperial Bank of Commerce) computer system in the late 80's. If you deposited a cheque in the bank machine, it would immediately give you access to the funds. You could then withdraw the cash. But when they discovered the cheque, they'd put a hold on it. The bug was that your account would never go below zero. So if you had $0 in the bank, deposited a check for $450.30, then withdrew $450, you'd have $0.30. When they put the hold on the check, the balance would stay at $0.30 and after 2 days they would add another $450.30 into your account (for a total of $450.60).
When I figured out what happened, I alerted them (with statements and everything), but they never took the money back. In fact it took them years to fix the bug and I often profited from it since I was always living paycheck to paycheck at the time.
The thing is, coding is the easiest part of programming. "Making it work" is what a lot of people are interested in, but actually I find that's about 10% of the job. Finding out what you *actually* need to build (vs what you are building now) and writing it in a way that is understandable to the next programmer is the challenge. Flowchart "coding" doesn't help this at all. Programming languages are actually pretty good at representing what we want to say. I don't think this will change in my lifetime.
Slashdot Mirror
Here is my strategy for dealing with this situation:
1) Tell the salesmen that you have absolutely no problem with them telling the customer whatever they want. Their function is to make sales to customers. Your function is to write software. You won't try to tell them how to do their job, because quite frankly you aren't qualified to know what's best for sales. Of course the implication is that they shouldn't tell you how to write software, but you probably don't have to tell them this explicitly (well, it happened once that I had to say it...)
2) Show the salesman what you actually *are* going to deliver. Generally a list of use-oriented functionality is the best. You might be doing a lot of refactoring underneath, but they won't understand that. Only list what the user will see.
3) Probably what they are saying to the customer and what you are promising to deliver will not match. No matter how clueless they are, the salesmen will probably notice and tell you, "You had better do something to fix the situation". This is where you reiterate, "I can't tell you what to say to the customers, that's up to you. But this is what I plan to release. However, if you would like to substitute something on this list with something more important, I'd be happy to oblige."
4) Now they will still want it all. They will tell you that the whole company will go under unless you deliver everything. You can now say, "That's a shame. I like working here too. Well, if that's the way it is, I guess I'll go fix up my resume. It was great working with you." You only have to do this once (thank god). At this point the salespeople will say, "Well, maybe we can do something if you at least give us feature X".
5) Negotiate with the salespeople. But use each piece of functionality as a lego block. Its size is immutable, but you can put it in, take it out, put it in a different place etc. At every point make sure to point out that you are quite happy to allow the salesmen to choose what they want you to do. It's just that it doesn't all fit.
6) Sometimes you will run into the situation where the salesman will swear at you and tell you to go do something anatomically impossible. Then they will storm off. At this point it's important to let them go, but to go to your own management (or executive management if you have no manager) and explain, "The salesmen are upset and I understand their point of view. They can't have everything that they want. It's frustrating for me too. But I need them to choose what things are most important. If you could just have a chat with them so I can prioritize things properly I would really appreciate it." After this you will have no problems (unless the salesman in question *is* executive management, in which case you should jump ship as quickly as possible).
7) Probably you will have to go through this charade about 4 or 5 times. But each time it will get easier. There will be one last time where they will pull every dirty trick in the book. Just hang tough, because after that you will have no problems.
Hope this helps.
Git an Mercurial are fundamentally different from the others you mentioned. They are distributed version control systems. You are free to set up your own topologies and methods for synchronizing. The biggest disadvantage is in not being able to easily checkout partial trees. This affects your workflow. IMHO, it results in a better workflow since you are forced to decouple the release of separate projects. But I'm sure I would get some stiff arguments from some people on that point. (My main argument is that if the release is coupled, then everyone *needs* to have an updated version of the project. If they don't need to have an updated version of the project, then you should be thinking seriously about what version they *do* need)
Anyway, you may or may not like this way of doing things since it is quite different from what you are used to. But it's worth your time to check it out.
This is a stupid "me too" post, but hopefully it will lend credence to what you say.
I originally used SVN because at the time there weren't any other credible options. I moved to bzr because I wanted distributed version control and bzr's syntax seemed easier than Git. Now I'm in the processes of moving over to Git. Git's documentation has vastly improved and that's a big reason for my change. I can't even really understand why I thought it was more difficult than bzr now. I also think that if people tried Git they would find it easier to use than SVN in almost every circumstance (there are a few counter examples, however).
The SHA1 hashes may look scary at first, but it really is the best approach. Incremental revision numbers are meaningless because there's no way to determine the order of the revisions on the distributed branches. For important revisions on a public repository you can always use a tag.
Like you, one of the main features of Git is that I can understand what it's doing all the time and why it's doing it. Again, kudos to the people who improved the documentation, but a lot of this is also just good design.
I don't think you have to justify your use of a proprietary driver at all. You are, in fact, using a proprietary driver *in order run a proprietary piece of software*. It would rather stupid for someone to say that you should choose freedom in one case and not in the other.
I'm a huge fan of free software. From a user's perspective it is just better. When stuff doesn't work I can move to another vendor without losing the software I've grown used to. This is a massive advantage for me. Without software freedom I get locked into a single vendor who generally doesn't care about me. Having worked for proprietary software vendors for nearly half of my life, I understand all too well what their attitude is towards end users (can you say, "cost center"?) Free software forces vendors to place their customers well being first (otherwise they can, and will, walk to someone else).
I don't think anyone wants to deny you the right to run whatever software you choose (as long as you abide by the license agreement, and as long as you don't choose a platform with DRM that restricts what software you can run on it). Choosing proprietary software is unfortunate, though. I can understand why you do, if you have no choice. But choosing free software not only has the potential to help you, it can also help others. Free software projects thrive on use (even if the users don't pay money). So when you have the choice it would be great if you can try to use free software.
The last one got me pretty bad. The absolutely best thing I've found is running. The endorphins really help a lot. You may have to work up to it, though. If you're not already a runner then running for about 10 minutes a day and increasing slowly up to 30 minutes over a 2 month schedule is probably OK. Check out some beginning running web sites. Running in the morning is good because you'll feel better at the start of the day.
Also, give yourself time to recover. Getting dumped is just like any other injury; it takes time to heal. I gave myself 3 months, after which I said "Fuck it" and moved on. I also casually dated a lot over that time, but go at your own speed. Whatever works best for you.
Only marginally related but... I remember playing a rogue style game (who's name I forget) with huge maps. But the save file was tiny. I couldn't figure out how they did it until I looked at the source code. They generated the maps pseudo-randomly and saved the seed for the random number generator in the save file. As long as the maps were regenerated in the same order you would always end up with the same map. Not exactly compression, but it's a useful technique for avoiding saving pseudo-random information.
If you were a diabetic and we could find a cure for diabetes or give you a drug that removed all symptoms, which would you prefer?
Making you a slave to a drug is not the same as a cure. Making someone thin does not make them healthy. Even if you burn all the calories you eat, eating a high fat diet can kill you, for instance.
Does it mean that a drug would not be useful in some situations? No. But assuming that controlling symptoms removes the problem is a dangerous way to look at the world.
I'm not worried about X breakages, personally. I even have an Intel 945G and I can live with the problems its causing. What I can't live with is the extreme instability of Pulse Audio. It crashes my apps contstantly from broken pipes. OK, people should be checking their pipes. But Pulse Audio itself crashes very frequently (about every hour or so on my machine). Rhythmbox won't go for more than 10 minutes without either crashing or audio failing. This is incredibly bad for me.
I realize that it's probably due to older, underpowered hardware (3 year old cheap laptop), but this should not be happening. I've yanked Pulse Audio from my machine altogether now and it's a lot more stable. I was also getting lock ups in Firefox every hour or so. Now that I've dumped Pulse Audio, I've only had one lock up in the past 3 days (still can't figure that one out -- related to video drivers???).
So, I plead with Ubuntu developers: either fix Pulse Audio, or punt it. The extra features it has is *not* worth the massive pain that some people experience.
I've worked on some flops in my time too. At subsequent interviews I'm pretty candid about what went wrong. For example on one project it became clear that we were building a product that nobody would want to use. Eventually the project was canned because it was simply stupid. I'm invariably asked what I would do differently in those situations.
I respond that when I see a potential problem, I discuss it with my manager. I point out possible solutions and indicate the cost of remedial action. I try to explain what the consequences of ignoring the problem is. Usually they ask if that will solve the problem. I say, probably not. Because I am not running the project. I am only one voice and can only view the project from my perspective. I will honestly give feedback and and discretely point out potential problems. But business is about taking risk. I may not be able to fully understand the risks and potential benefits from my position. So in the end I will discuss problems, but I will accept decisions and do my best to fulfill my role. Sometimes the risk doesn't pan out and we are left with a failure. Even if I correctly predicted the failure, that doesn't mean it wasn't worth trying.
If the we developed a drug that allowed people to be thin while eating whatever they want, would that really help people who over eat? Surely this is treating just the symptom. They are still addicted.
Like you, I reject the idea that "will power" will help obese people improve their life. Changing your self is hard. You have to want to do it. You have to be able to imagine yourself as the person without the thing you are addicted to. And you have to be happy with that. Once you do that, will power is not an issue one way or another.
Helping people get thin does nothing to help them with their addiction.
Please re-read the book. I wish I had it here (my copy is about 5000 miles away at the moment), but I think what you just wrote is already there. A design pattern, by definition, is something that is intuitively used by many people, whether they know what it's called or not. IIRC you can't call it a pattern unless there are 3 independent implementations of it. So one of the biggest pluses for design patterns is in being able to recognize them in existing code and thereby understand it more easily.
The next thing to realize about design patterns is that they are supposed to be generative. In other words, the use of one pattern naturally leads to the use of another. In other words, it generates the need for that pattern. One of the best uses of design patterns is in refactoring. Quite often you'll look at the design and say, "OK, we've got a state pattern here. And the way it's shaped, we probably need command pattern.... Hey, where's the command pattern in this code? Oh... OK, so that's what's causing the problems."
I am in complete agreement with you that using design patterns as some sort of list of ingredients in a recipe will almost certainly lead to disaster. And I'm relatively sure that this is stated in the GoF book (first couple of chapters... but I admit it's been a long time since I read it). Unfortunately many people try to skip thinking and don't realize that the random use of patterns won't actually make their code any better.
If you look at the early accomplishments of the people in the GoF you will see that they were well ahead of the curve when it comes to understanding these subtleties. So I'm quite sure these issues were well understood, although perhaps they could have been communicated better.
I never really did Scrum, but on several XP teams we had daily standups in the morning. However, I *never* invited the manager. In fact, I explicitly told the manager he wasn't welcome. A standup is about communicating small important issues to the rest of the team so that they don't have to discover it themselves. For instance, "I've changed the interface to this class, so if you're going to use it, please come and talk to me." It should never, ever be about tracking progress!!!!!! In XP there is an iteration plan, in Scrum there's a backlog. Either way that document tracks progress. A manager should never, ever ask "How far are you in your task", or "Do you think you'll finish in time" or "What have you done". He can look at the plan to see what is crossed off the list (and if you're really on the ball you've got people independently verifying that the acceptance tests are acceptable). It's up to *you* to warn people if you think your task won't fit in the time remaining. Everything else can be determined by looking at the plan/backlog.
Agile should be *easy* on you from this perspective. It's one of the reasons it's called agile. If you're not finding it this way you're doing it wrong (IMHO -- of course flame wars have been started on less). Ideally you should never talk to your manager. All information up and down the chain should be transparent. This leaves your manager free to act solely as a shit shield. Unfortunately most managers are too micro-managing to do agile properly.
Wow, lots of replies, but very few that are useful. Unfortunately I'm probably too late to get this modded up, but let's try...
First and foremost you need to realize that "getting a boy/girlfriend" is not like getting a pizza. It's not like an achievement in WoW. It's not a goal. If you treat it as such, you will be all uptight, needy and hopeless. It is simply choosing to spend time with someone and having them choose to spend time with you. It's simple, natural and normal.
If it's so simple and natural and normal, why are there some people for whom it seems impossible? First, let me reassure you: You aren't a freak if you don't have a GF/BF. Well, you might be a freak anyway, but freakiness doesn't necessarily rule out getting a partner. The reason you are single is because you have chosen (probably unconsciously) to be single. You aren't willing to accept what you need to do/be in order to get a partner.
First thing you need to do: learn from Fenyman. He said that the secret to sleeping with girls is (wait for it)... asking them. That's right. You need to be upfront and OK with your desire to have a partner. You need to have courage. When the opportunity arises to create a romance with someone (who you probably just met), then you have to take it. Don't think about it. Don't hesitate. Just do it.
I know. You have all sorts of excuses about why you can't do that. You're shy. You're fat. You're ugly. You've been turned down too many times before. You don't want to scare the person off. None of that matters now. You must be absolutely insensitive to those things. Turn your brain off and go with your hormones. If it's being offered, take what you want. And don't under any circumstances start thinking, "Well, maybe I shouldn't because I don't know if it's really best for the other person"!!!!
This leads me to my next point. You are a jerk. You probably don't know it, though. You probably think you are a nice guy/nice girl. Well, you aren't. You're a jerk. Nice people are open and honest enough with their feelings to reach out to someone. You always hold back. You always underestimate the other person. You never let them take responsibility for themselves. The so-called jerks that you think about (the ones who are successful dating and have a million friends/lovers)... they are nice guys/girls. Study them.
I'm not saying that you have to treat people badly (quite the opposite). Definitely a lot of these people are selfish and self-centered. They can be idiotic. They can be mean. But in terms of making friends and lovers, they are nice people. You must learn from them. Get to know them. Admire the things that are good and emulate them. Probably this means taking a huge ego hit and accepting the jocks and low-brow people into your circle of friends.
Which leads me to my next point. Dating is fun. Making friends is fun. Partying is fun. If you aren't having fun, probably you are letting unimportant things bother you. You need to be confident. When one of your new jock friends puts you down, laugh and tell him to stick it where the sun don't shine. But don't let it bug you, even one little bit. Probably you'll have to practice having people insult you for a while until you don't take it seriously any more. Then you can laugh and party with the best of them.
In the dating scene, you will often find yourself in awkward or difficult situations. Being able to laugh and have a good time even when the world is falling to pieces is incredibly sexy. Check out the current Dr. Who to understand the attitude you need. Don't take shit from anyone, but also don't let unimportant things bug you. Just have fun!!!!
Those are the important things. There's one last thing. Respect yourself. Respect means thinking you are important enough to worry about. If you don't think so, then nobody else will either. If you are fat, get thin. If you are unhealthy due to lack of exercise, exercise. If you have bad breath, bad teeth, b
I wish I could answer this question. Then maybe I could figure out why it doesn't work for me. Pulse audio crashes on me constantly (mean time between crashes is about 1 hour). Not only that, but under load applications trying to write to pulse audio will fail and will never again be able to play sound (or more likely crash, actually...). If I am doing anything on my computer and trying to use rhythmbox at the same time things will be crashing every 5 to 10 minutes.
I *do* have an older and lower spec laptop, though. I suspect that's part of my problem. I've also got an Intel 945GM graphics card and I'm using the work-arounds to get decent video performance with compiz, but that's resulted in a horrible memory leak in compiz (I don't blame compiz, though -- I'm pretty sure it's the video driver). So I'm often running in low memory conditions. This causes latency with PulseAudio, I think, contributing to the problems.
But it's no joke... when I upgraded to Jaunty pretty much *everything* broke :-( How hard is it to downgrade again?
Sure we could. But I don't trust you, so I'm gonna have to ask you to drop the gun first. Once you do that, I'll drop my own, too... I promise! Honest!
OK.
When a soldier joins an army it is often said that they join to protect their beliefs and way of life. They are willing to die for those ideals. An army of peace may not fight, but many may die. I would join such an army, even if I die because I believe in peace and it is integral to my way of life. This is not my idea, but I still believe it.
I was around then. My parents had a Betamax VCR. It was *definitely* better than my friend's VHS. But within a very short time you couldn't rent movies on Beta. When I bought my first VCR it was VHS simply for that reason. My parents still had the Beta for years and years afterwards. If I wanted to tape something I often did it at my parent's place because the quality was noticeably better.
Now I can't comment on exactly caused VHS to win, but that was my experience.
Lots of good replies here, so I won't touch on whether or not code reviews are beneficial. But one thing jumps out at me from the question:
"I'm a development manager... I asked my boss to consider whether it was worth spending so much time on examining built code..."
I hate to say it, but you are the wrong people to be considering this question. Code reviews are for programmers. It's good to hear that your reviews are developer led, but you've got some serious problems if you are trying to make this decision on your own. In fact, I'd go so far as to say that you have serious problems if you are attempting to make this decision at all.
Certainly, a development manager's role will involve some coaching (unless you hire a senior developer whose job is specifically geared to coaching the developers -- something I highly recommend). In that coaching role, you could of course guide inexperienced developers towards practices that work well for the team. But at some point practices should be self-selected. The developers can see much better than you can what is worth doing and what isn't.
It's appropriate to gather metrics and ask question about what is effective and what isn't. It can be a launching point for good discussion. But if your opinion of your developers is so low that you think you should make this decision, then you've got problems. Either you need to replace your developers or (more likely) get an attitude adjustment.
He's not being misleading, he's just not telling you everything. They are distributing the library without an attached patent license. *They* have a patent license for the library. The question is whether or not distribution requires the patent license.
The heart of the issue is whether or not the functionality is used in the redistribution. I'm quite certain his take is that it isn't. The *running* of the application is what uses the functionality. Thus the user requires a license, not the distributor. Google is redistributing the library, but clearly they intend it to be "as is" without a patent license. If the user feels they need a patent license then they need to get one.
This is a weakness of V2.1 of the LGPL. Contrast the wording in V2.1 with that in V3 (section 11) and you can see what's causing the problem. In V3 you have the clarification, ""Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid." In other words it relies on the patent if the *user's* use of the software requires the patent.
Basically Google are covering their ass and simultaneously going against the spirit of the LGPL. But they are probably in the clear legally. Personally I think they are being weasels.
This is right on, for programming jobs, anyway. I can tell you that while a masters might get your resume through HR (along with 150 others), it isn't going to mean squat to the people *actually* hiring you. I've hired many, many people and not once did I even think about a masters degree. The only hiring managers I knew who favored people with masters degrees were absolute twits (and there weren't even very many of them).
Another thing to keep in mind -- 2 years of academics is 2 years of not getting paid. It takes a pretty big salary differential to overcome that loss.
It's apache, which is more free than GPL.
While this is an informative post, modding it insightful is a bit trollish. If your definition of "free" means "less restricted", then it is certainly true. If your definition of "free" refers to the "free" as commonly used in "free software", then the statement is meaningless. Either it is free (gives me the 4 freedoms) or it isn't. There isn't "more" or "less".
By saying it is "more free than the GPL" you are making a distinction which is completely unnecessary in this context. The Apache license is both free as in "has few restrictions" and free as in "free software". So you can merely say that the Apache license is a "free license" as opposed to Microsoft's "shared source" licenses.
I, for one, am getting tired of these pointless political jabs.
What makes you think open-source drivers automatically makes them suck less?
There are some people (I am included in that group) for whom non-free software carries a certain minimum suckage, so to speak. It is true that if I have no alternative, I will use non-free software. But if I can do what I need to do I'll pick free software even if the alternative has more functionality. I'll save the rant about the value of freedom for the end user for another time. But I place a very high value on that freedom.
For example, I have an Intel 945GM card in my laptop. The 3D drivers in Linux suck very badly (sorry if anyone working on it is insulted), performance wise. Basically, I can play no games on it. My $50 NVidia graphics card *from 5 years ago* has 2 or 3 times the performance. But, if I were really worried about it, I could do something. The reason I moved from the NVidia card was a bug in the proprietary driver several years ago that caused me not to be able to do my work for some time (forget off hand the details). I felt powerless to do anything. And, for me, that sucked far more than the crappy 3D performance on my Intel card.
Just because it's open source doesn't mean it doesn't suck. The Intel drivers have always had serious performance problems. Now this. I wish there was someplace else to turn. On the other hand the binary blobs suck precisely because they are binary blobs.
What this rant needs is: "I should get off my butt and fix the damn Intel drivers".
Yeah, I have to agree with this. I'm living in Shizuoka prefecture in Japan and it gets "Florida hot" and then some (I lived in Tallahassee for a year when I was a kid). In the school where I work we *do* have air conditioning. It's set at 28 degrees C. I don't have air conditioning in my house. I use a hand fan during the day and an electric fan at night. If it's really hot I wear a wet bandana on my head. You get used to the heat. Hell, it's barely even warm here compared to places like India.
Definitely not true. There used to be a bug somewhere in the CIBC (Canadian Imperial Bank of Commerce) computer system in the late 80's. If you deposited a cheque in the bank machine, it would immediately give you access to the funds. You could then withdraw the cash. But when they discovered the cheque, they'd put a hold on it. The bug was that your account would never go below zero. So if you had $0 in the bank, deposited a check for $450.30, then withdrew $450, you'd have $0.30. When they put the hold on the check, the balance would stay at $0.30 and after 2 days they would add another $450.30 into your account (for a total of $450.60).
When I figured out what happened, I alerted them (with statements and everything), but they never took the money back. In fact it took them years to fix the bug and I often profited from it since I was always living paycheck to paycheck at the time.
The thing is, coding is the easiest part of programming. "Making it work" is what a lot of people are interested in, but actually I find that's about 10% of the job. Finding out what you *actually* need to build (vs what you are building now) and writing it in a way that is understandable to the next programmer is the challenge. Flowchart "coding" doesn't help this at all. Programming languages are actually pretty good at representing what we want to say. I don't think this will change in my lifetime.