Are you sure you're not just making stuff up about how you think a large company works? Assuming they passed any security/background checks, they'd need to provide SSN, address, banking details, next of kin etc. The phantom employee would show up on all email lists and reporting structures. They would be allocated a manager and at some point you would assume scheduled to do work of some kind. Even on day one, a pass would need to be issued, a photograph taken, an induction course participated in, a desk, phone, computer allocated and set up. Even the shittest manager usually actually meets their staff day one or soon after. You'd need buy in from a serious number of people to create a fake employee. I doubt the attempt would work. Now if he got himself onto a vendor list or faked approval for some kind of mythical online subscription or service, that might work.
I had the same thing in 1999. I too have a US passport thoug I never lived there so my visit was to catch up with friends before travelling on to South America. On my entry form I just said "friends" on the "where are you staying" bit. One of the customs or immigration guys (I think customs for extra WTF) started asking a bunch of questions about where I was staying. I started to explain I had no idea what my friend's address was before realising I didn't even have to even tell him. Luckily common sense prevailed and I told him that I was a citizen and unless he could prove my passport was a forgery, where I go or stay was none of his fucking business. I was told I'd be singled out for a cavity search next time I entered the US.
Funny thing was, the day before I left for South America we phoned around and visited about 5 shops trying to get some guns so we could have a laugh and shoot stuff (cans/trees) as is "my right" as an American. Two US citizens sporting federal ID absolutely could not get anyone to sell us weapons (guns or catapaults or anything) despite protests that "we absolutely have to have projectile weapons before tomorrow when I fly out".
I cannot imagine not being in jail had those shopping trips happened a year later.
Exactly. And this is why you should not, as a general case really try to document intent in code other than in reference to requirements. The requirements, specifications, release notes and high-level architecture design documents are there to describe the nature and features of the product. The code is how it gets you there and how it works should be self documenting.
The "should this value be 20 or 21", "should it ask a or b", "does it report x or y" kind of things are not to be found in code but in product documents.
That way they behaviour and features are testable, publishable, sellable, supportable. Not every interested party can read code. Furthermore, in mature organisations the code is often a small part of a large operational process.
This is why we have requirements and functional specifications. If it's ambiguous, then fine, ask the BA/Customer/whoever and fix up the documentation and then the code. Generally speaking though, this question should be your last one, not the first one.
I hate paperwork as much as the next guy, but there is a fair bit of truth in the attitude that a system with undocumented requirements and functionals is impossible to pass testing. When you have customers, this actually translates to potential contractual issues and whether payment should be forthcoming or withheld. You need something that can be signed off and accepted by all parties, not "it doesn't feel right to me".
If you are filing a patent as part of your job then the "extra effort" becomes part of your duties doesn't it? As with anything your boss asks you to do, you need to allocate and schedule the time to do it. Why would anyone, employee or employer, expect this to be done on the filer's personal time? Does the scenario you are raging at actually exist?
You are starting from an impossible position. The Java app will have a 1000 lines of meta-manager-interface-factory-facades before doing a stroke of useful work. So either the Java wins because there are no identifiable bugs in its operation (i.e. there is no operation) or it loses for not actually being capable of providing *any* functionality in 1000 lines.
Personally I like a good balance. Get the basic requirements and understanding of the problem then get design and architecture right and you can live with fairly fluid requirements while they still fall within the original vision. So I work like that - a good strong, solid up front design to address core functionality then the actual development can usually accommodate shifts and additional stuff.
You're dead right - nobody knows everything but you can have a good crack at it and accept the reality that you won't get it right first time.
I have a VM on my personal laptop for the same reason. Work lives on the VM (well actually I mainly use remote desktop to my office computer) and my personal stuff stays personal. Turn off the VM and work's gone for the day. No emails, files, applications or anything cross that boundary and I only have to have one device. It works well. And work pays my internet but I wouldn't mind if they didn't.
Haha. I think the same about Windows. Love Windows or hate it, at least (untill recently) you could pretty much know where everthing was or how to access stuff(File|save, Tools|options, right-click|properties). What an improvement over what was there before.
Now, as you correctly point out, almost every site you visit you have to learn it. Not progress in usability that's for sure.
The Web - great delivery mechanism, sucky user experience.
And OT - incubating the worst developers we've ever had since I used to type in listings from magazines:)
Thanks. While I agree it's a possible or even likely scenario, I'm pretty sure virtulisation in this case would be an unnecessarily wasteful solution. Don't most O/S s allow you to apply security at the application/service level? I'm not saying you're wrong in that people think like that, but I'd expect admins to know that it's not the only way. Anyway, thanks for the reply.
Genuine question:
Why is virtualisation so good? We have
- Multi-tasking o/s that generally have resource allocation/partitioning/caps etc
- Database software that runs multiple instances/databases/schemas
- Web servers that run multiple sites on multiple threads
So why is virtualisation better than stuffing your physical servers to capacity rather than adding overhead of multiple o/s
Seems like the logical end-point will be a single-process O/S run off a mega hypervisor, which is almost indistinguishable from an O/S
Oracle actually does a pretty good job. It's also got a language that as far as I can tell is Java with PL/SQL syntax (as well as actual Java). Depends on your definition of language I guess.
True, but most developers seem to forget that they're there to solve a problem for a cost. So many times I've had the "we don't need it to support multiple database vendors, it doesn't need to be configurable to the nth degree, we need it to do *this* and *this* only" conversations. I see their motivations and occasionally it's great but the approach is often overzealous and applied too broadly.
How? The light is going to go green at the same time no matter what your speed so unless you get ahead of it I don't see how you can get to your destination earlier. Can you explain in more detail?
Yes they do get evaluated. What you are reading is 99% uninformed bullshit from people too far away from what running a company actually takes. Managers are under pressure to do unreasonable stuff too but generally the rank & file don't see most of it. It's just different and often even less fair/more ridiculous. "wah wah wah! Management won't let me spend a year to refactor code so it does exactly the same as it does now and want me to fill in a timesheet". "wah wah wah - How can I run an effective team to achieve x, y and z if you don't give me a budget for people or gear but you'll fire me if I don't".
Same but different and even more unpleasant believe it or not.
There's no harm in using regex etc to perform some basic up-front validation, but the best and only way to prevent this crap is to use paramaterised queries. It's all you need to do to. (Oh, and escape your output appropriately to your target environment as well)
I'd be interested to know if on a busy server fragmentation is even that much of a bad thing when you're not just loading files into memory such as a database. With dozens of jobs all using different bits of different files, the heads are going to be all over the place anyway. Hell, a fragmented file might accidentally cause a few wins if occasionally bits of it are close to whatever else was just read.
Hear Hear.
The "Wow!" factor for me is the fact it puts the translation back over the original in the same colour & font. The translation part has been done to one degree or another for years but combined with the overlay & real-time it's a spectacular achievement.
I have been in IT for 25 years and am so often underwhelmed by "new" developments that it's refreshing to be impressed. Mind you, my phone is 7 years old and I only got home internet 6 months ago so am sometimes easily impressed by old stuff too.
Great post. Thanks.
I may be wrong/living in the past here but I was under the impression that another limitation of GPUs is that they "cheat". By that I mean that in that some of their operations produce perfectly acceptable results when translated to graphic/visible operations but at the expense of some mathematical correctness, meaning you have to watch out how you apply some of those algorithms to non-graphical applications.
You seem to know what you are talking about - maybe you can tell me if this is the case?
Not quite what I meant. SQL injection occurs when you don't parameratise your queries. If you do this then there is no reason to clean the input. This is a form of escaping rather than sanitizing, so I kind of class that as output because it's passing my data across some interface that will interpret my data in some way.
So, I basically agree:
1 - escape output according to the requirements of your destination system
2 - in the case of SQL this is achieved by using parameters.
I still maintain that "cleaning" input is wrong because you never know where it's going to go.
Slashdot Mirror
Maybe it would be easier to issue a 99c note!
Are you sure you're not just making stuff up about how you think a large company works? Assuming they passed any security/background checks, they'd need to provide SSN, address, banking details, next of kin etc. The phantom employee would show up on all email lists and reporting structures. They would be allocated a manager and at some point you would assume scheduled to do work of some kind. Even on day one, a pass would need to be issued, a photograph taken, an induction course participated in, a desk, phone, computer allocated and set up. Even the shittest manager usually actually meets their staff day one or soon after. You'd need buy in from a serious number of people to create a fake employee. I doubt the attempt would work. Now if he got himself onto a vendor list or faked approval for some kind of mythical online subscription or service, that might work.
I had the same thing in 1999. I too have a US passport thoug I never lived there so my visit was to catch up with friends before travelling on to South America. On my entry form I just said "friends" on the "where are you staying" bit. One of the customs or immigration guys (I think customs for extra WTF) started asking a bunch of questions about where I was staying. I started to explain I had no idea what my friend's address was before realising I didn't even have to even tell him. Luckily common sense prevailed and I told him that I was a citizen and unless he could prove my passport was a forgery, where I go or stay was none of his fucking business. I was told I'd be singled out for a cavity search next time I entered the US.
Funny thing was, the day before I left for South America we phoned around and visited about 5 shops trying to get some guns so we could have a laugh and shoot stuff (cans/trees) as is "my right" as an American. Two US citizens sporting federal ID absolutely could not get anyone to sell us weapons (guns or catapaults or anything) despite protests that "we absolutely have to have projectile weapons before tomorrow when I fly out".
I cannot imagine not being in jail had those shopping trips happened a year later.
A flag would be more efficient than counting posts :)
Also, why would you convert a perfectly good number to a string? Bloody XML generation...
Exactly.
And this is why you should not, as a general case really try to document intent in code other than in reference to requirements. The requirements, specifications, release notes and high-level architecture design documents are there to describe the nature and features of the product. The code is how it gets you there and how it works should be self documenting.
The "should this value be 20 or 21", "should it ask a or b", "does it report x or y" kind of things are not to be found in code but in product documents.
That way they behaviour and features are testable, publishable, sellable, supportable. Not every interested party can read code. Furthermore, in mature organisations the code is often a small part of a large operational process.
This is why we have requirements and functional specifications. If it's ambiguous, then fine, ask the BA/Customer/whoever and fix up the documentation and then the code. Generally speaking though, this question should be your last one, not the first one.
I hate paperwork as much as the next guy, but there is a fair bit of truth in the attitude that a system with undocumented requirements and functionals is impossible to pass testing. When you have customers, this actually translates to potential contractual issues and whether payment should be forthcoming or withheld. You need something that can be signed off and accepted by all parties, not "it doesn't feel right to me".
If you are filing a patent as part of your job then the "extra effort" becomes part of your duties doesn't it? As with anything your boss asks you to do, you need to allocate and schedule the time to do it. Why would anyone, employee or employer, expect this to be done on the filer's personal time? Does the scenario you are raging at actually exist?
You are starting from an impossible position. The Java app will have a 1000 lines of meta-manager-interface-factory-facades before doing a stroke of useful work. So either the Java wins because there are no identifiable bugs in its operation (i.e. there is no operation) or it loses for not actually being capable of providing *any* functionality in 1000 lines.
Personally I like a good balance. Get the basic requirements and understanding of the problem then get design and architecture right and you can live with fairly fluid requirements while they still fall within the original vision. So I work like that - a good strong, solid up front design to address core functionality then the actual development can usually accommodate shifts and additional stuff. You're dead right - nobody knows everything but you can have a good crack at it and accept the reality that you won't get it right first time.
I have a VM on my personal laptop for the same reason. Work lives on the VM (well actually I mainly use remote desktop to my office computer) and my personal stuff stays personal. Turn off the VM and work's gone for the day. No emails, files, applications or anything cross that boundary and I only have to have one device. It works well. And work pays my internet but I wouldn't mind if they didn't.
But isn't "random detritus pulled out of someone's ass" pretty much the definition of the internet?
Haha. I think the same about Windows. Love Windows or hate it, at least (untill recently) you could pretty much know where everthing was or how to access stuff(File|save, Tools|options, right-click|properties). What an improvement over what was there before. :)
Now, as you correctly point out, almost every site you visit you have to learn it. Not progress in usability that's for sure.
The Web - great delivery mechanism, sucky user experience.
And OT - incubating the worst developers we've ever had since I used to type in listings from magazines
Thanks. While I agree it's a possible or even likely scenario, I'm pretty sure virtulisation in this case would be an unnecessarily wasteful solution. Don't most O/S s allow you to apply security at the application/service level? I'm not saying you're wrong in that people think like that, but I'd expect admins to know that it's not the only way.
Anyway, thanks for the reply.
Genuine question:
Why is virtualisation so good? We have
- Multi-tasking o/s that generally have resource allocation/partitioning/caps etc
- Database software that runs multiple instances/databases/schemas
- Web servers that run multiple sites on multiple threads
So why is virtualisation better than stuffing your physical servers to capacity rather than adding overhead of multiple o/s
Seems like the logical end-point will be a single-process O/S run off a mega hypervisor, which is almost indistinguishable from an O/S
Oracle actually does a pretty good job. It's also got a language that as far as I can tell is Java with PL/SQL syntax (as well as actual Java). Depends on your definition of language I guess.
True, but most developers seem to forget that they're there to solve a problem for a cost. So many times I've had the "we don't need it to support multiple database vendors, it doesn't need to be configurable to the nth degree, we need it to do *this* and *this* only" conversations. I see their motivations and occasionally it's great but the approach is often overzealous and applied too broadly.
How? The light is going to go green at the same time no matter what your speed so unless you get ahead of it I don't see how you can get to your destination earlier. Can you explain in more detail?
All good in IE6 too.
Yes they do get evaluated. What you are reading is 99% uninformed bullshit from people too far away from what running a company actually takes. Managers are under pressure to do unreasonable stuff too but generally the rank & file don't see most of it. It's just different and often even less fair/more ridiculous. "wah wah wah! Management won't let me spend a year to refactor code so it does exactly the same as it does now and want me to fill in a timesheet". "wah wah wah - How can I run an effective team to achieve x, y and z if you don't give me a budget for people or gear but you'll fire me if I don't".
Same but different and even more unpleasant believe it or not.
There's no harm in using regex etc to perform some basic up-front validation, but the best and only way to prevent this crap is to use paramaterised queries. It's all you need to do to. (Oh, and escape your output appropriately to your target environment as well)
I'd be interested to know if on a busy server fragmentation is even that much of a bad thing when you're not just loading files into memory such as a database. With dozens of jobs all using different bits of different files, the heads are going to be all over the place anyway. Hell, a fragmented file might accidentally cause a few wins if occasionally bits of it are close to whatever else was just read.
Could be difficult. It was a wireless laptop running on a battery. Police have no leads.
Thanks. I'm here all week.
Hear Hear. The "Wow!" factor for me is the fact it puts the translation back over the original in the same colour & font. The translation part has been done to one degree or another for years but combined with the overlay & real-time it's a spectacular achievement.
I have been in IT for 25 years and am so often underwhelmed by "new" developments that it's refreshing to be impressed. Mind you, my phone is 7 years old and I only got home internet 6 months ago so am sometimes easily impressed by old stuff too.
Great post. Thanks.
I may be wrong/living in the past here but I was under the impression that another limitation of GPUs is that they "cheat". By that I mean that in that some of their operations produce perfectly acceptable results when translated to graphic/visible operations but at the expense of some mathematical correctness, meaning you have to watch out how you apply some of those algorithms to non-graphical applications.
You seem to know what you are talking about - maybe you can tell me if this is the case?
Not quite what I meant. SQL injection occurs when you don't parameratise your queries. If you do this then there is no reason to clean the input. This is a form of escaping rather than sanitizing, so I kind of class that as output because it's passing my data across some interface that will interpret my data in some way.
So, I basically agree:
1 - escape output according to the requirements of your destination system
2 - in the case of SQL this is achieved by using parameters.
I still maintain that "cleaning" input is wrong because you never know where it's going to go.