I agree. Code should be pretty obvious and the use of decent names, structure etc make it so. Of course there will be some gnarly bits that need special treatment, but I tend to stick with that
I think a more interesting discussion would be the equivalent of comments & documentation for and from non-coders such as BAs & DBAs, project managers etc. For example:
UML/Class diagrams
Data models
Business rules
Functional manual
Lexicon
What about applications that do not use the application server but connect directly to the database? Application rules (for want of a better description) should certainly live in the application server. General business rules should live in the database.
I disagree. Data can have business logic. Databases have multiple clients (in the application sense). What better place to implement business logic? The minute you code your business logic anywhere else it becomes a one-off, specific to that application. A major skill is identifying those rules that are application specific compared with those that are data or organisationally specific.
Personally I don't think there is one. One poster said "portability". Using a stored procedure interface you can pretty much cover this one, although admittedly not without writing one SP layer per database.
I'd also point out that many products are not required to be portable, especially in-house systems. Those that are are rarely optimal on any platform-the worst of both worlds.
OT, but if your statistics are up to date then Oracle should pick the most selective index (assuming it's going to use one at all). I would consider speaking to your DBA and making sure the stats are current.
A lot of good points. To pick up one one - the whole "data corruption" problem - that, IMO, stems from a blinkered approach to systems design. Enforcing business, data rules & integrity in the database seems to have been forgotten. This is a shame because it is far an away the best place for them providing virtually all the functionality of the shiny new application servers we're using today. Tools for the job! Applications and interfaces come & go. Data is for life. Look after it properly.
Everyone should be working themselves out of a job, or at least a task. I try to perform each task twice. Once to work a problem through and the other to either automate, script, change a process or whatever to the point where I never have to do it again. There will always be other stuff to do, and it stops things from becoming boring.
Oracle seems to work ok with 10-100000 users because they have been doing it for years. One of the reasons they can is because huge effort is put into everything possible being non-serial.
If you're still writing sort routines then I'd suggest you are looking at problems at a lot lower level than the enterprise and are happy to reinvent the wheel. Personally I prefer to use libraries & existing, proven technology where it exists.
The way you store your data is important. It is everything. Applications come and go. Trends change, technology changes, but the underlying facts and accumulation of information about your business, clients and competition does not. That is why you need to care how you store your data. Would you use a bank that stored its accounts in an.XLS file on Bob the manager's C drive?
Sure if something takes 30 seconds you might want to look for the underlying problem. Consider though that even if the particular operation takes 100th of a second, once you serialize you are limiting yourself to 3000 users before you are GUARANTEEING 30 second access times.
Not good.
Perhaps a larger version could be used to create enough power for the transmitters (or whatever they are called). Not quite sure about the power requirements of this though..
If you're using a decent IDE then the SC should be nicely integrated and is never intrusive. I, like many others, use it all the time on single projects for many of the reasons stated in other posts. It's really not hard if your IDE does it all for you.
I have a US passport but don't live there. On one of my very infrequent visits (1999 or so) I left that blank. The guy asked my about it, I told him I hadn't memorised my friend's address, he was waiting for me in the carpark. Besides, I CAN STAY WHERE EVER I LIKE IN MY OWN COUNTRY. He let me go but threatened me with a cavity search next time. There hasn't been a next time, but I wish I'd reported him!
All well & good, but there is usually more to a program/system/product than the code. Business analysts can't generally read code. Database guys can't generally read code. Support guys can't generally read code. UML provides a mechanism to document relationships & interactions much more clearly than code. A few examples from a system I am working on now: How are the client & account related? Can clients share an account? Does the portfolio belong to the client or the account? What happens to the portfolio when a stock is sold, what actors are involved, what events occur?
Each of these can be cleanly described on a single screen, understood by non-technical people. This whole XP thing, while an effective development method tends to overlook the fact that code is only part of the story.
Are you talking about 2 phase commit? If so, I'd say that this support is essential when you're in the scenario you just described about outsourcing. In fact your argument is backwards. When each component of a transaction is in a third party product then you need them. If each component is yours you can integrate & do without. Of course I may have missed your point entirely.
I remember being told that it was the least likely to be 'dialed' by line noise and the like. I doubt that would be a problem now but both of these sound likely, especially when you go back to the earliest days.
We need you to DONATE MONEY (paypal button on openoffice.org).
That's why you should charge money for your work and not give it away. That's when I go to the grocery store I have to pay for the products I leave with rather than leave any spare change in a bucket by the door.
My 2 cents (or local free equivalent).
Your first paragraph is very true. Your last shows the importance of being able to identify useful things to measure and, I'm afraid to say, your inability to do so.
The middle bit is hard to define, but you can't generalise. To write software using JBuilder or Visual Studio for example is orders of magnitude (at least one anyway) more productive than using vi and javac/gcc. The important thing about all these cases is that under the covers is the raw command line tools and that that GUI is a wrapper on top of these. The users get the benefit of all the goodies in the GUI with the ability to run unattended command line scripts.
Anybody else have good suggestions for dealing with a business-geek who wants to give his customers access to code, but who doesn't want to end up in the quagmire of supporting a thousand hacked versions of his software?
If you intend to allow them to change it then you can't avoid the problems you mentioned. How can you?
You could try making the functionality more data-driven. That way you can release one immutable version that has varying behaviour depending on the set up rather than code. Depending on the language, you could also provide hooks where it can call custom classes/dlls or whatever I suppose.
Whatever happens, once you give away the code with a view to them changing it you've lost the game. You may want to consider if your product is really meeting their needs if you find yourself with a custom installation per site.
Why not look beyond the code? Analyze the needs of your client base and produce a single version that encompasses all their needs. You'll need to take on more of a business analysis role here. Perhaps it's time to expand...?
Good luck, whatever you decide.
This is about being in a public place, in control of something that can (and certainly does) have an effect on those around them and requires a licence to operate. Surely it is legitimate to ensure people are driving under the terms & conditions their licence and insurance was issued.
Slashdot Mirror
Amazing isn't it. Whatever happened to 'the right tools for the job'.
I agree. Code should be pretty obvious and the use of decent names, structure etc make it so. Of course there will be some gnarly bits that need special treatment, but I tend to stick with that
I think a more interesting discussion would be the equivalent of comments & documentation for and from non-coders such as BAs & DBAs, project managers etc.
For example:
UML/Class diagrams
Data models
Business rules
Functional manual
Lexicon
All more interesting.
What about applications that do not use the application server but connect directly to the database? Application rules (for want of a better description) should certainly live in the application server. General business rules should live in the database.
I disagree. Data can have business logic. Databases have multiple clients (in the application sense). What better place to implement business logic? The minute you code your business logic anywhere else it becomes a one-off, specific to that application. A major skill is identifying those rules that are application specific compared with those that are data or organisationally specific.
Personally I don't think there is one. One poster said "portability". Using a stored procedure interface you can pretty much cover this one, although admittedly not without writing one SP layer per database.
I'd also point out that many products are not required to be portable, especially in-house systems. Those that are are rarely optimal on any platform-the worst of both worlds.
OT, but if your statistics are up to date then Oracle should pick the most selective index (assuming it's going to use one at all). I would consider speaking to your DBA and making sure the stats are current.
A lot of good points. To pick up one one - the whole "data corruption" problem - that, IMO, stems from a blinkered approach to systems design. Enforcing business, data rules & integrity in the database seems to have been forgotten. This is a shame because it is far an away the best place for them providing virtually all the functionality of the shiny new application servers we're using today. Tools for the job! Applications and interfaces come & go. Data is for life. Look after it properly.
Everyone should be working themselves out of a job, or at least a task. I try to perform each task twice. Once to work a problem through and the other to either automate, script, change a process or whatever to the point where I never have to do it again. There will always be other stuff to do, and it stops things from becoming boring.
Oracle seems to work ok with 10-100000 users because they have been doing it for years. One of the reasons they can is because huge effort is put into everything possible being non-serial. .XLS file on Bob the manager's C drive?
If you're still writing sort routines then I'd suggest you are looking at problems at a lot lower level than the enterprise and are happy to reinvent the wheel. Personally I prefer to use libraries & existing, proven technology where it exists.
The way you store your data is important. It is everything. Applications come and go. Trends change, technology changes, but the underlying facts and accumulation of information about your business, clients and competition does not. That is why you need to care how you store your data. Would you use a bank that stored its accounts in an
Sure if something takes 30 seconds you might want to look for the underlying problem. Consider though that even if the particular operation takes 100th of a second, once you serialize you are limiting yourself to 3000 users before you are GUARANTEEING 30 second access times.
Not good.
Or just walk through any major US city late at night.
Do you think you could keep recipes on it as well?
Perhaps a larger version could be used to create enough power for the transmitters (or whatever they are called). Not quite sure about the power requirements of this though..
I thought it was designed to blend in with the Windows XP scheme.
If you're using a decent IDE then the SC should be nicely integrated and is never intrusive. I, like many others, use it all the time on single projects for many of the reasons stated in other posts. It's really not hard if your IDE does it all for you.
I have a US passport but don't live there. On one of my very infrequent visits (1999 or so) I left that blank. The guy asked my about it, I told him I hadn't memorised my friend's address, he was waiting for me in the carpark. Besides, I CAN STAY WHERE EVER I LIKE IN MY OWN COUNTRY. He let me go but threatened me with a cavity search next time. There hasn't been a next time, but I wish I'd reported him!
All well & good, but there is usually more to a program/system/product than the code.
Business analysts can't generally read code. Database guys can't generally read code. Support guys can't generally read code. UML provides a mechanism to document relationships & interactions much more clearly than code. A few examples from a system I am working on now:
How are the client & account related?
Can clients share an account?
Does the portfolio belong to the client or the account?
What happens to the portfolio when a stock is sold, what actors are involved, what events occur?
Each of these can be cleanly described on a single screen, understood by non-technical people.
This whole XP thing, while an effective development method tends to overlook the fact that code is only part of the story.
Are you talking about 2 phase commit? If so, I'd say that this support is essential when you're in the scenario you just described about outsourcing. In fact your argument is backwards. When each component of a transaction is in a third party product then you need them. If each component is yours you can integrate & do without. Of course I may have missed your point entirely.
I remember being told that it was the least likely to be 'dialed' by line noise and the like. I doubt that would be a problem now but both of these sound likely, especially when you go back to the earliest days.
Love it.
My 2 cents (or local free equivalent).
I can feel my karma slipping away.....
Your first paragraph is very true. Your last shows the importance of being able to identify useful things to measure and, I'm afraid to say, your inability to do so.
The middle bit is hard to define, but you can't generalise. To write software using JBuilder or Visual Studio for example is orders of magnitude (at least one anyway) more productive than using vi and javac/gcc. The important thing about all these cases is that under the covers is the raw command line tools and that that GUI is a wrapper on top of these. The users get the benefit of all the goodies in the GUI with the ability to run unattended command line scripts.
You could try making the functionality more data-driven. That way you can release one immutable version that has varying behaviour depending on the set up rather than code. Depending on the language, you could also provide hooks where it can call custom classes/dlls or whatever I suppose.
Whatever happens, once you give away the code with a view to them changing it you've lost the game. You may want to consider if your product is really meeting their needs if you find yourself with a custom installation per site.
Why not look beyond the code? Analyze the needs of your client base and produce a single version that encompasses all their needs. You'll need to take on more of a business analysis role here. Perhaps it's time to expand...?
Good luck, whatever you decide.
This is about being in a public place, in control of something that can (and certainly does) have an effect on those around them and requires a licence to operate. Surely it is legitimate to ensure people are driving under the terms & conditions their licence and insurance was issued.