[...]followed by several paragraphs that have nothing to do with the original question, but instead tell how to use (yawn) unit testing.
He could have connected the dots a little better, but he described a perfectly good approach. The poster asked How do you perform complete system regression testing? and a good way to do that is to break the system down.
Note that the post you're griping about talked not just about unit testing, but integration testing. Both are important to getting an app like this well tested. If you have a system A->B->C then unit testing A, B, and C and then testing integrations A->B and B->C gets rid of most of your bugs.
You do this because full end-to-end testing is much more expensive for the same level of quality than lower-level testing. In my experience it's still worth doing some end-to-end testing on a system with full unit and integration tests, but those aren't so much about catching interesting bugs as avoiding stupid mistakes and about verifying that what you've built is what the product manager intended, rather than a plauible but wrong interpretation of their requests.
I've had contracts that (if I hadn't insisted on altering them) would have prohibited me from working on outside code, because I was supposed to direct my "full productive effort" to my corporate masters.
I can imagine certain circumstances where that would even be legit. If somebody had worked for many years at PARC or Google or someplace that's more a lifestyle than a job, I could buy that they put everything they had into work, and that the employer keeping all the code would be reasonable.
But otherwise, even if somebody had a contract like that as an excuse, I'd be suspicious if they couldn't come up with some code they'd written. I'd still probably give them the benefit of the doubt, but the next stage of the interview is the pair programming session, so I'd find out soon enough if they were serious techies or just really smooth talkers.
Why would anyone choose to spend thousands of dollars on something when they could get it for free? It's because they believe they will spend more money in the long run.
It also could be because people will pay a fair bit to mitigate risks that they don't understand. Tax time reminds me that I'm that way with accounting. Doing the tax forms myself would save me the dough I spend on my accountant, and it would probably be cheaper in the long run, even including my time. But taxes and the IRS are such a complicated world that I don't even know what might go wrong. I'm glad to pay the accountant a generous fee just so that I can focus on things that matter to me.
Also, the incentives for employees in mid-sized businesses can be different than those in larger or smaller companies.
Large businesses have the time and money to look at all the solutions and pick the best ones, rather than doing what everybody else is doing. If you can convert something from Windows and Linux and make the company net better off including conversion costs, you'll advance your career.
Small businesses will often follow along with the herd, but because they're pretty cost-sensitive and accustomed to trying to improve things, many people in them will be willing to try new, innovative stuff in the hopes that the risk will pay off.
But medium-sized businesses are, as you'd expect in between: a lot of IT projects aren't big enough that they can pay staff to really figure out the best choices, but they are comfortable enough that they'll write a check to make the problem go away.
I have never been asked for "work samples." I seriously doubt they are even asking for examples of work done at previous companies. That would be insane (releasing another companies IP?!).
I completely agree. I often ask for code samples when I'm interviewing programmers. If somebody were foolish enough to bring in IP from a former employer, there's no way I'd hire them; I don't have time to ride herd on the clueless.
Also, if somebody doesn't have any of their own personal code laying around, or some open-source stuff they've released, I probably wouldn't hire them, either unless there was some other clear sign that they really loved their work. I have zero use for programmers who aren't in the field primarily because they like it.
It's a completely unnecessary waste of police time. If they are wasting their time chasing innocent idiots, they aren't chasing criminals.
So a store breaks the law, refuses to accept legal tender, and is so stubborn about it that they insist on calling the cops, and it's the fault of the guy who wants to pay with a 50?
What a crackpot. What is wrong with you that would make you do these things?
Some people like to cause a little trouble. What of it? The question isn't whether he likes that, but whether he uses his powers for good or for evil.
In this case, the guy seems to be getting people to act like people, rather than dumb-policy-following robots. It's more convenient for him, it's no less convenient for them, and it makes sense. And it happens to be the law. That seems like a net good.
The people who worry me aren't the ones who are a little jerky for a good cause. They're the well-intentioned ones who do a lot of harm. E.g., people supporting abstinence-only sex ed, or opposing needle exchanges for addicts. They mean well, but they don't seem to get that in the end it's the outcome that matters.
Quite simply, it's cool. It puts a little something unusual into people's lives... makes an otherwise boring, same-old-same-old, day for these counter clerks into something to remember... at least for a few hours.
And to this, let me say amen!
One summer I worked as a clerk in a 24-hour store, akin to 7-11. After the novelty wore off, I was always thankful for the small percentage of customers who would just treat you like a human being, rather than some sort of poorly automated till. And the ones who would actually go out of their way to perk up my night, I loved.
Amazingly (despite much assault) we still believe in "innocent until proven guilty".
Well, since 9/11 we've been working to become much more consistent on that point. We also still believe in "innocent until proven guilty". It's just that the current administration believes that it's ok to handcuff, hood, and jail innocent people indefinitely.
This is 3 or 4 degrees of separation from my vanity domains. MAPS decided to blacklist the entire freaking colocation facility until the spam stopped.
This is called a boycott. Suppose I don't like Shell's behavior in Nigeria. If I boycott Shell, I will harm lots of Shell employees besides the handful responsible for the policies I don't like. Do you oppose that as well?
They feel like it's better to penalize many just because a few bad eggs are mixed in. Well, they need to tune their blacklists because I don't trust them.
Collective punishments are illegal and amoral (in most morality codes at least.)
Sorry, which law outlaws that?
Most laws can be looked at as collective punishment. Why are drugs outlawed? Because a small fraction of drug users fail to use them responsibly. In the US telemarketers were pretty much shut down because some percentage of them were a nuisance. We pick an arbitrary age of majority because collectively people under 18 seem to be notably less responsible than people above it. And so on, and so on.
Yes, a small company, perhaps. It seems to work out OK, if you can survive the startup expenses.
Don't forget the risk of a bomb or a recall. He does 3-4 models a year; do half that and you're depending for the year on one or two models. It's much more likely that a surprise problem will bring you to your knees.
The thing is truly a joy. There are so many beautiful little touches, things that one person in a hundred would never notice, but that add up to a great experience.
For example, take a look at the backglass artwork. You can see that all of the windows (which are individually lit by bulbs behind them) have little scenes in them. Except the top-left one looks dark and empty. But really, it has a bulb that comes on occasionally to show the silhouette of Cousin It. How does it work? On the back of the backglass art, which is normally blank, they did another printing run with just the Cousin It silhouette in an opaque metallic ink.
The same care extends into the software. One of the objects of the game is to open a bookcase so you can shoot the ball into the Vault, a hole behind the bookcase. But maybe one game in a hundred, you'll hit the ball in some weird way where it flies through the air, bounces off the glass, and ends up in the vault even when the bookcase is closed. Most games would just decide that it was an error and spit the ball back out. But Addams Family has Gomez say, "Dirty pool, old man. I like it!" Then it skips you ahead in the game, opening the bookcase and locking the ball for multiball.
Just from playing it, it's clear that the makers of it were masters of their craft, and that they loved what they did. The Addams Family pinball machine has always been an inspiration to me in the stuff I make, even when it's something much less sexy, like business software.
Whenever I see "is a powerful, ultra-high performance" I just stop reading right there. Excess positive adjectives are a sure-fire sign of misrepresentation.
Excess knee-jerk negativity, however, is usually perfectly accurate.
Giving the library away does not help us do our work any better nor does it help us win additional contracts, but it will help our competitors.
That depends a lot on the code you release. There are companies that I've done business with solely because they released some open-source code that got me interested in what else they could do.
Aside from the advertising benefit, I generally find it nicer to deal with companies who get the whole open source thing. They often have a positive-sum view of the world that makes negotiations much easier than people who are too focused on zero-sum games or those who feel entitled to capture every cent of potential revenue.
It helps a lot when you can easily point out that the tools you want open sourced have nothing to do with the core function of the company[...]
Agreed. My experience is that businesses feel very proprietary about software that relates to what the business does for money, but rarely give a damn about library code or generic tools once you explain the distinction.
It also helps if your bosses already know that you're using a number of open-source tools or libraries, and if they hear about it when you submit patches. That way when you ask to open-source something, they'll be able to think of it as just another open-source tool, one that other people will be improving.
Also, when I make this pitch, I generally offer to do it on my own time. That way they don't worry about the things your not doing when you tidy things up for initial release.
Re:Well maybe the realized that it's hard
on
The Baby Bootstrap?
·
· Score: 1
Doubly so if you have no goals, and your task is just to "learn". It would come back with garbage.
Wow, isn't that the truth? I sat down at the computer with no paticular goals, and I've been reading Slashdot for the last hour.
I'm not sure why my previous post got marked "Troll". But for the record, I'm sincere, and I think my many previous posts here on server-side development bear that out.
I like Java and do most of my professional work in it, but I think EJBs were overhyped, and a lot of their use, along with fancy application servers, was managerial pursuit of silver bullets, rather than sound technical work.
I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect. So, i am using SqlMaps.
Perhaps you should try actually using Hibernate.
First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.
Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.
Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.
It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching means that many apps will be faster. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.
There is nothing easier to scale then webapps in the world. You can cope with any amount of traffic by just throwing more hardware on the problem in a share nothing environment like php, perl or ruby/rails.
Perhaps you should ammend that statement to be "There is nothing easier in the world to scale than trivial webapps".
Amen to that. If there's an app that actually shares nothing, there's not a lot of need for it to be a web application; you can run it at home. Most apps actually share quite a bit, and the essential question of scaling is which bits really need to be shared and by how much.
Further, it's pretty silly to say that throwing hardware at something is easy. It may be easy for the programmer, but it can be hell on the sysadmins and the CFO. Especially when the throw-hardware-at-it approach requires ever-larger boxes, where $/performance increases exponentially.
Plus, managers like technology that is generally popular in case you get hit by a bus.
Professional programmers should like that, too. There's something very pleasant about going on vacation, leaving your cellphone behind, and knowing that your team can happily keep going with the project while you're gone.
My understanding is that a good J2EE implementation is capable of scaling to thousands of clients (one article I read claimed a 250,000 client load), the ruby implementation might start crawling after as little as 50 clients.
Having seen the guts of a fair number of alleged enterprise-scale Java applications, I encourage people not to believe the hype.
If you have a really good understanding of what it means to build a scalable web app, some of the J2EE stuff may be of use to you in some circumstances. But unless you really know which pieces to use and when, you're better off not using any of it. Why? Two reasons:
First, if you use the wrong pieces or the right pieces in the wrong places, you'll make things much worse than they'd be otherwise. On several projects I have made an application run 10x faster, consume a tenth the memory, and become much easier to work on by ripping out all the EJB nonsense.
Second, most projects just don't need massive scalability right now, and very few of them will ever need more than you can squeeze out of modern commodity hardware. By paying for scalability too soon, you slow development, forgoing features or spending capital that could mean the difference between success and failure for your project.
What a contract actually means is determined not by common sense, but by relevant contract law (which you don't know) and case law (which you don't know). If you really care about what a contract is actually enforcably commiting you to, hire a lawyer.
Amen to that. We all know what happens when amateurs write source code; similar things happen when amateurs write legal code.
If you can afford to tap the attorney occasionally (lawer friends are great to have), then tell the PHB that you need to pass the contract by your "legal department" and ask if there is a contact person at the client company that you should coordinate contractual changes with. This gives you more bargaining power and eliminates the "well that actually means" responses.
Anybody who signs contracts should absolutely have a professional look them over. Not only can they tell you which parts are scary, they can also tell you which parts don't matter, and therefore aren't worth burning client goodwill on. The cost of getting a lawyer is noticeable, but the cost of *not* getting a lawyer to look it over can be truly dumbfounding.
However, never, ever say something like "legal department" unless you actually have one. Just tell them you have to run it by your lawyer. The kind of people fooled by puffery this obvious are rarely worth having as clients.
Slashdot Mirror
[...]followed by several paragraphs that have nothing to do with the original question, but instead tell how to use (yawn) unit testing.
He could have connected the dots a little better, but he described a perfectly good approach. The poster asked How do you perform complete system regression testing? and a good way to do that is to break the system down.
Note that the post you're griping about talked not just about unit testing, but integration testing. Both are important to getting an app like this well tested. If you have a system A->B->C then unit testing A, B, and C and then testing integrations A->B and B->C gets rid of most of your bugs.
You do this because full end-to-end testing is much more expensive for the same level of quality than lower-level testing. In my experience it's still worth doing some end-to-end testing on a system with full unit and integration tests, but those aren't so much about catching interesting bugs as avoiding stupid mistakes and about verifying that what you've built is what the product manager intended, rather than a plauible but wrong interpretation of their requests.
I've had contracts that (if I hadn't insisted on altering them) would have prohibited me from working on outside code, because I was supposed to direct my "full productive effort" to my corporate masters.
I can imagine certain circumstances where that would even be legit. If somebody had worked for many years at PARC or Google or someplace that's more a lifestyle than a job, I could buy that they put everything they had into work, and that the employer keeping all the code would be reasonable.
But otherwise, even if somebody had a contract like that as an excuse, I'd be suspicious if they couldn't come up with some code they'd written. I'd still probably give them the benefit of the doubt, but the next stage of the interview is the pair programming session, so I'd find out soon enough if they were serious techies or just really smooth talkers.
Why would anyone choose to spend thousands of dollars on something when they could get it for free? It's because they believe they will spend more money in the long run.
It also could be because people will pay a fair bit to mitigate risks that they don't understand. Tax time reminds me that I'm that way with accounting. Doing the tax forms myself would save me the dough I spend on my accountant, and it would probably be cheaper in the long run, even including my time. But taxes and the IRS are such a complicated world that I don't even know what might go wrong. I'm glad to pay the accountant a generous fee just so that I can focus on things that matter to me.
Also, the incentives for employees in mid-sized businesses can be different than those in larger or smaller companies.
Large businesses have the time and money to look at all the solutions and pick the best ones, rather than doing what everybody else is doing. If you can convert something from Windows and Linux and make the company net better off including conversion costs, you'll advance your career.
Small businesses will often follow along with the herd, but because they're pretty cost-sensitive and accustomed to trying to improve things, many people in them will be willing to try new, innovative stuff in the hopes that the risk will pay off.
But medium-sized businesses are, as you'd expect in between: a lot of IT projects aren't big enough that they can pay staff to really figure out the best choices, but they are comfortable enough that they'll write a check to make the problem go away.
I have never been asked for "work samples." I seriously doubt they are even asking for examples of work done at previous companies. That would be insane (releasing another companies IP?!).
I completely agree. I often ask for code samples when I'm interviewing programmers. If somebody were foolish enough to bring in IP from a former employer, there's no way I'd hire them; I don't have time to ride herd on the clueless.
Also, if somebody doesn't have any of their own personal code laying around, or some open-source stuff they've released, I probably wouldn't hire them, either unless there was some other clear sign that they really loved their work. I have zero use for programmers who aren't in the field primarily because they like it.
It's a completely unnecessary waste of police time. If they are wasting their time chasing innocent idiots, they aren't chasing criminals.
So a store breaks the law, refuses to accept legal tender, and is so stubborn about it that they insist on calling the cops, and it's the fault of the guy who wants to pay with a 50?
What a crackpot. What is wrong with you that would make you do these things?
Some people like to cause a little trouble. What of it? The question isn't whether he likes that, but whether he uses his powers for good or for evil.
In this case, the guy seems to be getting people to act like people, rather than dumb-policy-following robots. It's more convenient for him, it's no less convenient for them, and it makes sense. And it happens to be the law. That seems like a net good.
The people who worry me aren't the ones who are a little jerky for a good cause. They're the well-intentioned ones who do a lot of harm. E.g., people supporting abstinence-only sex ed, or opposing needle exchanges for addicts. They mean well, but they don't seem to get that in the end it's the outcome that matters.
Quite simply, it's cool. It puts a little something unusual into people's lives... makes an otherwise boring, same-old-same-old, day for these counter clerks into something to remember... at least for a few hours.
And to this, let me say amen!
One summer I worked as a clerk in a 24-hour store, akin to 7-11. After the novelty wore off, I was always thankful for the small percentage of customers who would just treat you like a human being, rather than some sort of poorly automated till. And the ones who would actually go out of their way to perk up my night, I loved.
Amazingly (despite much assault) we still believe in "innocent until proven guilty".
Well, since 9/11 we've been working to become much more consistent on that point. We also still believe in "innocent until proven guilty". It's just that the current administration believes that it's ok to handcuff, hood, and jail innocent people indefinitely.
Hey, let's not be dramatic here. Neutering would be fine.
This suggests strongly that the anti-forgery measures on the Euro bills are just plain not good enough.
That, or there's slightly more incentive to counterfit a currency used by 360 million people than one accepted by 16 million people. Or both.
This is 3 or 4 degrees of separation from my vanity domains. MAPS decided to blacklist the entire freaking colocation facility until the spam stopped.
This is called a boycott. Suppose I don't like Shell's behavior in Nigeria. If I boycott Shell, I will harm lots of Shell employees besides the handful responsible for the policies I don't like. Do you oppose that as well?
They feel like it's better to penalize many just because a few bad eggs are mixed in. Well, they need to tune their blacklists because I don't trust them.
Don't trust them? Great! Don't use them.
Collective punishments are illegal and amoral (in most morality codes at least.)
Sorry, which law outlaws that?
Most laws can be looked at as collective punishment. Why are drugs outlawed? Because a small fraction of drug users fail to use them responsibly. In the US telemarketers were pretty much shut down because some percentage of them were a nuisance. We pick an arbitrary age of majority because collectively people under 18 seem to be notably less responsible than people above it. And so on, and so on.
Yes, a small company, perhaps. It seems to work out OK, if you can survive the startup expenses.
Don't forget the risk of a bomb or a recall. He does 3-4 models a year; do half that and you're depending for the year on one or two models. It's much more likely that a surprise problem will bring you to your knees.
Without doubt one of my favorite machines made.
The thing is truly a joy. There are so many beautiful little touches, things that one person in a hundred would never notice, but that add up to a great experience.
For example, take a look at the backglass artwork. You can see that all of the windows (which are individually lit by bulbs behind them) have little scenes in them. Except the top-left one looks dark and empty. But really, it has a bulb that comes on occasionally to show the silhouette of Cousin It. How does it work? On the back of the backglass art, which is normally blank, they did another printing run with just the Cousin It silhouette in an opaque metallic ink.
The same care extends into the software. One of the objects of the game is to open a bookcase so you can shoot the ball into the Vault, a hole behind the bookcase. But maybe one game in a hundred, you'll hit the ball in some weird way where it flies through the air, bounces off the glass, and ends up in the vault even when the bookcase is closed. Most games would just decide that it was an error and spit the ball back out. But Addams Family has Gomez say, "Dirty pool, old man. I like it!" Then it skips you ahead in the game, opening the bookcase and locking the ball for multiball.
Just from playing it, it's clear that the makers of it were masters of their craft, and that they loved what they did. The Addams Family pinball machine has always been an inspiration to me in the stuff I make, even when it's something much less sexy, like business software.
Whenever I see "is a powerful, ultra-high performance" I just stop reading right there. Excess positive adjectives are a sure-fire sign of misrepresentation.
Excess knee-jerk negativity, however, is usually perfectly accurate.
Giving the library away does not help us do our work any better nor does it help us win additional contracts, but it will help our competitors.
That depends a lot on the code you release. There are companies that I've done business with solely because they released some open-source code that got me interested in what else they could do.
Aside from the advertising benefit, I generally find it nicer to deal with companies who get the whole open source thing. They often have a positive-sum view of the world that makes negotiations much easier than people who are too focused on zero-sum games or those who feel entitled to capture every cent of potential revenue.
It helps a lot when you can easily point out that the tools you want open sourced have nothing to do with the core function of the company[...]
Agreed. My experience is that businesses feel very proprietary about software that relates to what the business does for money, but rarely give a damn about library code or generic tools once you explain the distinction.
It also helps if your bosses already know that you're using a number of open-source tools or libraries, and if they hear about it when you submit patches. That way when you ask to open-source something, they'll be able to think of it as just another open-source tool, one that other people will be improving.
Also, when I make this pitch, I generally offer to do it on my own time. That way they don't worry about the things your not doing when you tidy things up for initial release.
Doubly so if you have no goals, and your task is just to "learn". It would come back with garbage.
Wow, isn't that the truth? I sat down at the computer with no paticular goals, and I've been reading Slashdot for the last hour.
I'm not sure why my previous post got marked "Troll". But for the record, I'm sincere, and I think my many previous posts here on server-side development bear that out.
I like Java and do most of my professional work in it, but I think EJBs were overhyped, and a lot of their use, along with fancy application servers, was managerial pursuit of silver bullets, rather than sound technical work.
I don't trust/want something to auto generate my sql tables and such based on my objects. That leads to problems, since the queries can't be tuned or maybe you don't get what you expect. So, i am using SqlMaps.
Perhaps you should try actually using Hibernate.
First, Hibernate works just fine with hand-generated SQL tables. Indeed, that's the only thing I've ever used it for. Second, you can happily tune your queries through hinting to Hibernate and careful choices of object relationshiops, and the recently released Hibernate 3 allows to you hand-write all the SQL if you choose.
Third, you're kinda missing the point of Hibernate. Using Hibernate akin to using Java itself in that both of them hide a lot of details about the underlying operations so that the programmer can spend their time and energy focusing on the essential problems rather than the details of the technology.
Most programmers doing SQL stuff in Java let the weirdness of SQL databases distort their designs heavily. They don't really do OO programming because they spend all their time thinking about database operations. Hibernate lets you do good OO design and have 95% of the SQL rituals handled under the hood.
It's possible that you lose some performance to Hibernate, although I never noticed it, and Hibernate's built-in caching means that many apps will be faster. But really, if performance is all that important to you, you shouldn't be using a database at all. Serializing all your data every time you need to work with it is incredibly expensive. There's a reason that things like Google and Quake aren't built on top of SQL databases.
Amen to that. If there's an app that actually shares nothing, there's not a lot of need for it to be a web application; you can run it at home. Most apps actually share quite a bit, and the essential question of scaling is which bits really need to be shared and by how much.
Further, it's pretty silly to say that throwing hardware at something is easy. It may be easy for the programmer, but it can be hell on the sysadmins and the CFO. Especially when the throw-hardware-at-it approach requires ever-larger boxes, where $/performance increases exponentially.
Plus, managers like technology that is generally popular in case you get hit by a bus.
Professional programmers should like that, too. There's something very pleasant about going on vacation, leaving your cellphone behind, and knowing that your team can happily keep going with the project while you're gone.
My understanding is that a good J2EE implementation is capable of scaling to thousands of clients (one article I read claimed a 250,000 client load), the ruby implementation might start crawling after as little as 50 clients.
Having seen the guts of a fair number of alleged enterprise-scale Java applications, I encourage people not to believe the hype.
If you have a really good understanding of what it means to build a scalable web app, some of the J2EE stuff may be of use to you in some circumstances. But unless you really know which pieces to use and when, you're better off not using any of it. Why? Two reasons:
First, if you use the wrong pieces or the right pieces in the wrong places, you'll make things much worse than they'd be otherwise. On several projects I have made an application run 10x faster, consume a tenth the memory, and become much easier to work on by ripping out all the EJB nonsense.
Second, most projects just don't need massive scalability right now, and very few of them will ever need more than you can squeeze out of modern commodity hardware. By paying for scalability too soon, you slow development, forgoing features or spending capital that could mean the difference between success and failure for your project.
What a contract actually means is determined not by common sense, but by relevant contract law (which you don't know) and case law (which you don't know). If you really care about what a contract is actually enforcably commiting you to, hire a lawyer.
Amen to that. We all know what happens when amateurs write source code; similar things happen when amateurs write legal code.
If you can afford to tap the attorney occasionally (lawer friends are great to have), then tell the PHB that you need to pass the contract by your "legal department" and ask if there is a contact person at the client company that you should coordinate contractual changes with. This gives you more bargaining power and eliminates the "well that actually means" responses.
Anybody who signs contracts should absolutely have a professional look them over. Not only can they tell you which parts are scary, they can also tell you which parts don't matter, and therefore aren't worth burning client goodwill on. The cost of getting a lawyer is noticeable, but the cost of *not* getting a lawyer to look it over can be truly dumbfounding.
However, never, ever say something like "legal department" unless you actually have one. Just tell them you have to run it by your lawyer. The kind of people fooled by puffery this obvious are rarely worth having as clients.