"Thats interesting. You have the business rules on both sides. The code that implements it and the on the database tables that has the results. If the business rules changes then you have to change both the code and previously existing result data you've stored on the database, correct?"
Nope, there's little logic in the database. There's only a few functions to help me pull data in some places. If the server script needs data it wasn't provided with, then it uses the app side to retrieve whatever it needed.
The only thing that really changes in the database according to user needs is adding new columns (or tables on rare occasions).
Also, the database is the record of somebody's transaction. Even if the business rules change, the records must not... I'd suspect most apps are this way, but then I don't know what you're working on. You're right though, if there's no need to have a record of a calc or rule, then there's probably no good reason to keep it in the database.
"Both ways every single record is screwed up (or just the important ones that matter in our case)."
Only if the bug isn't caught. If it somehow manages to get through testing, a bug is usually found pretty quickly. (Think user riots and lots of hand-wringing.:-) We have a lot of controls here because those records translate to paper checks somewhere.
Anyway, I'm not saying it's the best design, but re-running the business rules on every read struck me as a massive waste of CPU. I couldn't do it in my case, but you have made me think of some situations where it could make some sense.
I think we're not talking about the same thing. For the apps I write, for example, the business logic often entails complicated financial calculations that aggregate several fields from multiple database tables. The server-side script does this and the result is stored in the database. The output from the business logic, in this case, is part of the record and is appropriately stored with it.
There's no problem running reports and (shudder) Excel against the database, because the business logic has been applied. I'm not sure what you're doing in order to simply read from storage, which makes me think we're misunderstanding each other.
It wouldn't be possible for me to change the data on the read for a number of reasons. Most importantly, if it has to be changed, then the record in the database is wrong and it counts as a bug against my app. I also need to have a record of the structures the users create, even if the business logic changes. (It is a Bad Thing if the record changes and some customer suddenly owes more money on their next bill.) Also, these scripts are long and difficult even when written in a convenient language like Python, when implemented in stored procs on every read, reports would take days to complete.
Oh, one last point, from a pessimistic viewpoint. If I were to screw up the on-save business layer, that's not good. But if I were to screw up an on-read design, then every single record is broken. That's a lot worse...
The unfortunate thing is that the second you think about changing the database, you start worrying about all those procs you'd have to port. There shouldn't be a direct connection to the database for all but the simplest of apps. Otherwise you're talking about a lot of pain incurred when the logic, the database, or the app changes.
The database layer's job is to store data. If you need a stored proc to assist with that, then it's the best tool. But business data is best implemented in a layer far abstracted from anything else. You should be able to use it as a wholly separate piece from the application, the database, or anything else, really.
The other point I wanted to make was that your business layer typically needs access to other things besides just the other data. There's only so much junk you can collect up in the app layer to pass to a stored proc before your app logic is riddled with code that doesn't make sense for anything but that specific business layer. When the time comes to port to another business, you're screwed...
This is coming from a guy who very painfully re-implemented an app designed like you've described. And the blasted thing is still stuck on Oracle.:-)
- Because my favorite radio station was bought out and sucks now. (Half the time they're playing some crazy techno on the rock station, which I don't like.)
- Ads. If I were listening to the radio on the way to work, half the time I wouldn't get any music. Just ads.
- Concentration. I like to listen to music while I program, but ads or talking in general will distract me.
I like radio, though. I just wouldn't care to have it on my iPod...
It's not enough to just have smart people. You have to have some smart people from different departments to get stuff done and to consider all the possibilities. I'd suggest the poster should learn more about "cross functional" teamwork.
There's a lot of crazy stuff in teamwork research, but not all of it is BS. A team that works well together can tackle any project you through at them with great results...
When we have a large project, it'll typically involve people from IT, Systems, a project manager and selected users that it'll effect. The users involved know the system well and are chosen because when they say something is broken on the test system, the guys in IT understand what the heck they're talking about in their emails. It works pretty well.
Yeah, I've seen their "compatibility." Basically, you have to put an underscore before most of your function calls, and half of them don't work correctly. Running a formerly Posix app on Windows still requires a great deal of porting.
Anyway, SFU doesn't provide any more Posix support than the already bad support included with Windows. SFU is mostly for horrid implementations of NFS and NIS. (Seriously, I spent a long time once trying to get Windows to work as a client on a NIS network. It has got a lot of problems.)
"Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts."
Uhm, yes. Interoperability takes adherences to standards and a lot of testing and work. If we all use the same software, that's not interoperability, that's software hegemony. Silly.
I'll tell you about Microsoft's interoperability. It's Apache Axis having to add an API just because the MS libraries don't send information about a SOAP call's return type. That's the true meaning of interoperability.
Are you talking about Windows? Yeah, I wasn't... Otherwise, most other OSes either have make installed or can fetch it easily...
Windows does have nmake, but it drove me nuts that it's necessary to restart apps to replace in use jar files. oy. So the guys I was trying to help get started on the source ended up getting shiny new Linux boxes.
"... you can define tasks so you get the following steps just by pressing a button: CVS souce update, souce compile, junit testing with reports mailed to developers, javadoc generation, JAR packaging all into a tidy application."
Uhm... I already do half of these things with make, but they're all trivial.
"No offence, but would like to see your little makefile handle a large project; with hundreds of programmers with different OSes, IDEs and subprojects."
make has been doing this for years...
"Sometimes a wheel comes along that is a significant improvement on previous ones."
I think you overestimate it's improvements, is all.
Actually, I wondered why you were being so defensive until I realized that I forgot the smiley at the end of the last post. I don't really care what you use to compile your stuff, just don't force me to use it.:-)
That's nice and all, but the stuff javac finds is the easiest kind of bug to kill. Heck, once you've been developing for a while, you tend to not make those mistakes anyhow. And it's not really much of a time-saver for me, since compilation from inside emacs will take me to the line I goofed.
I just don't get all the fuss.:-)
Honestly, I tried eclipse. But not for anything too serious because it wanted to move all of my source files to make a project... That's irritating, to say the least.
Easy. Every developer's system should already have `make`, so there's no need for other dependencies or learning some crazy IDE just to compile some Java. Heck, every IDE and text editor should be able to run `make`.
The following makefile target is about as advanced as I needed, and it's mostly scripting. It's a little something I added when we got some programmers involved in the source using fancy IDEs that couldn't even format multi-line statements correctly. So I use emacs to fix it for them:
indent:
for f in `ls *.java`; do \
emacs --batch -l ~/.emacs -l ${TOPDIR}/batch-indent.el --eval "(batch-indent \"$$f\")"; \
done;
New ways are all fine and dandy until you realize you just reinvented something another programmer has been doing for years. He'll probably laugh and mumble something about "those kids these days."
You'll need a hardware SSL loadbalancer, with redundancy:
http://www.coyotepoint.com/e450.htm
(Two of those).
You'll need at lease two web servers with CPU and RAM. The requirements on these boxes really depend on the app. I'd make them dualies at least, with fast Xeon processors (Good bang for the buck). A couple gigs of ram each. You can add servers to the load balancer later if you need to. Disk doesn't really matter, but I'd use a SCSI mirrored root volume for reliability.
The database needs to be redundant, and since you think it'll be the bottleneck, an Oracle RAC setup would seem to fit your needs. I really don't like Oracle from a developer stand-point, but two big servers with Oracle running on raw disks for performance is a tough combo to beat. Expensive and long on the setup and install, though.
With all of that, you'd have a large initial investment, but something that would grow with your needs. You could add new apps to this setup later on, as well. However, if you needed to run this on the cheap, the Linux Virtual Server project does a lot of this with simple Linux boxes.
If this is too expensive, the first thing to take out is the hardware SSL. I included it because I want them, not because I have 'em.:-) Check out pound:
http://www.apsis.ch/pound/
A couple Linux boxes with failover setup and you've saved a good 40-70 grand. Requires some expertise.
By pissing off Diebold, you'd anger a good deal of the most powerful people in the world. The people who control the combined forces of the FBI, CIA, NSA, the military, and everything in between.
And you'd just blackmail them (and commit a felony)? At best you could hope to blow the whistle and create a scandal, but your career would likely be over. That'd be very noble, but not really on par with "by the balls."
s'alright. I'll buy games on the PS2 now and run them smoothly on the PS3 later. You can buy them over again.:-)
Re:Security of Online Apps a Hurdle?
on
Firefox - The Platform
·
· Score: 5, Interesting
Personally, I have never used or considered using ActiveX since it only runs on Windows. What I know is it's a program, usually Visual Basic cab file, running within the browser. There have been several security problems, mainly stemming from the fact that once running, it has programatic access to the whole computer.
Other than the security issues, and that it only runs on Windows and within IE, I understand it's generally a pain to work with and debug. But it does allow you to run programs on the client and use normal Windows widgets in your design. Painfulness is measured differently by me than somebody who programs for Windows. I imagine they would disagree.
Somebody will correct me if I'm wrong on the ActiveX details here, I'm sure.:-)
XUL is meant for addressing the same problem -- bad interfaces on the web, but it takes a drastically different approach. The dialogs are described by lightweight XML files that are pretty painless to develop. The client programming is done in Javascript, which is not as bad as it sounds. The main problem Javascript faces is cross-browser support, which is negated by only using gecko. There's also a decent Javascript console which make it a lot easier to fix script errors in Mozilla than in IE.
The main advantage is everything is still done on the server, only a little user interface junk is left to the client to handle in Javascript, which is arguably where it belongs. You'd do the same in a normal webapp, write html and use Javascript to manipulate objects for a better user experience.
Also, I've seen far too many ActiveX programs that do database access from the client, for example. Typically, there's no security or verification of who's doing what at that level, a difficult thing to get right in any client. Often times you can take the ActiveX object and use it's own objects to access the database and change whatever you like. XUL leaves all of that up to the server which makes it easier to manage and more difficult for bad programmers to leave gaping security holes.
Anyway, there's no 'trusted' environment. All companies should prevent internal users from abusing the system.:-)
Uh... I think you misunderstood what all of this is about. Firefox *and* Mozilla already use a XML format called XUL for their interfaces. It's already in both of them, and there's no reason to change the browser to support any of the uses mentioned.
Heck, you don't have to install XUL to get it working, just browse to a.xul file and away you go.
-1, Ignorant
Re:Security of Online Apps a Hurdle?
on
Firefox - The Platform
·
· Score: 2, Interesting
You're absolutely right. My company, before I started, was using several Windows-only applications. One major DNA-based app died off when the software company was bought-out (which I've rewrote for the web, like you mentioned) and others have been moved to web-based services. That wasn't even at our prodding, soap and xmlhttp are getting huge in the Financial Industry.
I've recently started in on a XUL app (though not PHP and MySql -- JSP, LDAP and PostgreSql since we had that architecture). I think if the XUL interface designer gets some more polish and support for IDE functionality, this platform could be huge. Firefox is just getting started, but as it becomes popular this could be the next popular wave of free software usage.
Where I think you're wrong, though, is the amount of ActiveX/DNA apps companies are still locked into. They're shrinking rapidly. We've seen a large number of them get converted into webservices. At least in Banking, the software vendors seem to have realized we mostly all have our own internal apps anyway, and we don't want to admin yet another client install. I'd wager that's the same thing happening in other industries, albeit a bit slower. Banking is often among the first to implement new tech.
The main point is that admins are less likely to buy and implement anything that's not web-based since it means more work for them, so many apps are being rewritten. So far, that hasn't meant increased ActiveX usage, since banks are pretty hard-core about security and like to keep it turned off.
There's only one app that I can think of where there's not much of an alternative: ACT. I hate that program, but the sales people are addicted to it.:-)
Slashdot Mirror
"Thats interesting. You have the business rules on both sides. The code that implements it and the on the database tables that has the results. If the business rules changes then you have to change both the code and previously existing result data you've stored on the database, correct?"
:-) We have a lot of controls here because those records translate to paper checks somewhere.
Nope, there's little logic in the database. There's only a few functions to help me pull data in some places. If the server script needs data it wasn't provided with, then it uses the app side to retrieve whatever it needed.
The only thing that really changes in the database according to user needs is adding new columns (or tables on rare occasions).
Also, the database is the record of somebody's transaction. Even if the business rules change, the records must not... I'd suspect most apps are this way, but then I don't know what you're working on. You're right though, if there's no need to have a record of a calc or rule, then there's probably no good reason to keep it in the database.
"Both ways every single record is screwed up (or just the important ones that matter in our case)."
Only if the bug isn't caught. If it somehow manages to get through testing, a bug is usually found pretty quickly. (Think user riots and lots of hand-wringing.
Anyway, I'm not saying it's the best design, but re-running the business rules on every read struck me as a massive waste of CPU. I couldn't do it in my case, but you have made me think of some situations where it could make some sense.
I think we're not talking about the same thing. For the apps I write, for example, the business logic often entails complicated financial calculations that aggregate several fields from multiple database tables. The server-side script does this and the result is stored in the database. The output from the business logic, in this case, is part of the record and is appropriately stored with it.
There's no problem running reports and (shudder) Excel against the database, because the business logic has been applied. I'm not sure what you're doing in order to simply read from storage, which makes me think we're misunderstanding each other.
It wouldn't be possible for me to change the data on the read for a number of reasons. Most importantly, if it has to be changed, then the record in the database is wrong and it counts as a bug against my app. I also need to have a record of the structures the users create, even if the business logic changes. (It is a Bad Thing if the record changes and some customer suddenly owes more money on their next bill.) Also, these scripts are long and difficult even when written in a convenient language like Python, when implemented in stored procs on every read, reports would take days to complete.
Oh, one last point, from a pessimistic viewpoint. If I were to screw up the on-save business layer, that's not good. But if I were to screw up an on-read design, then every single record is broken. That's a lot worse...
The unfortunate thing is that the second you think about changing the database, you start worrying about all those procs you'd have to port. There shouldn't be a direct connection to the database for all but the simplest of apps. Otherwise you're talking about a lot of pain incurred when the logic, the database, or the app changes.
:-)
The database layer's job is to store data. If you need a stored proc to assist with that, then it's the best tool. But business data is best implemented in a layer far abstracted from anything else. You should be able to use it as a wholly separate piece from the application, the database, or anything else, really.
The other point I wanted to make was that your business layer typically needs access to other things besides just the other data. There's only so much junk you can collect up in the app layer to pass to a stored proc before your app logic is riddled with code that doesn't make sense for anything but that specific business layer. When the time comes to port to another business, you're screwed...
This is coming from a guy who very painfully re-implemented an app designed like you've described. And the blasted thing is still stuck on Oracle.
"Do you mind sharing some of these granted patents on the basics of computer science?"
IsNot
Yeah, evo is driving me nuts since to 2.0 upgrade. I'm thinking about downgrading because it seems to have lost all ability to handle incoming html.
:-)
Anyway, if you turn off 3d acceleration, X can run for a long time. I've got to restart WindowMaker every couple months, but I can deal with that.
Nothing like that. Here's some reasons:
- Because my favorite radio station was bought out and sucks now. (Half the time they're playing some crazy techno on the rock station, which I don't like.)
- Ads. If I were listening to the radio on the way to work, half the time I wouldn't get any music. Just ads.
- Concentration. I like to listen to music while I program, but ads or talking in general will distract me.
I like radio, though. I just wouldn't care to have it on my iPod...
oy.
Because Samba is GPL and the Samba project uses these protocols.
I kid you not, I got this from a fortune cookie yesterday:
:-)
"Every thinker puts some portion of an apparently stable world in peril."
(this page attributes that to John Dewey.)
Ah, but (this is on topic) perhaps the author uses emacs and trusts it to align the code correctly, which would make missing braces an obvious error.
:-)
We have learned about him from his code.
It's not enough to just have smart people. You have to have some smart people from different departments to get stuff done and to consider all the possibilities. I'd suggest the poster should learn more about "cross functional" teamwork.
There's a lot of crazy stuff in teamwork research, but not all of it is BS. A team that works well together can tackle any project you through at them with great results...
When we have a large project, it'll typically involve people from IT, Systems, a project manager and selected users that it'll effect. The users involved know the system well and are chosen because when they say something is broken on the test system, the guys in IT understand what the heck they're talking about in their emails. It works pretty well.
"Your point about running as admin all the time is a pretty valid one, though. But I'm not convinced that the UNIX user model is perfect either."
:-)
What is? I guess we'll just have to settle for "massively better."
Yeah, I've seen their "compatibility." Basically, you have to put an underscore before most of your function calls, and half of them don't work correctly. Running a formerly Posix app on Windows still requires a great deal of porting.
Anyway, SFU doesn't provide any more Posix support than the already bad support included with Windows. SFU is mostly for horrid implementations of NFS and NIS. (Seriously, I spent a long time once trying to get Windows to work as a client on a NIS network. It has got a lot of problems.)
"Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts."
Uhm, yes. Interoperability takes adherences to standards and a lot of testing and work. If we all use the same software, that's not interoperability, that's software hegemony. Silly.
I'll tell you about Microsoft's interoperability. It's Apache Axis having to add an API just because the MS libraries don't send information about a SOAP call's return type. That's the true meaning of interoperability.
Check here for the real story.
"Why? Not all people have Unix or program C."
:-)
Are you talking about Windows? Yeah, I wasn't... Otherwise, most other OSes either have make installed or can fetch it easily...
Windows does have nmake, but it drove me nuts that it's necessary to restart apps to replace in use jar files. oy. So the guys I was trying to help get started on the source ended up getting shiny new Linux boxes.
"... you can define tasks so you get the following steps just by pressing a button:
CVS souce update, souce compile, junit testing with reports mailed to developers, javadoc generation, JAR packaging all into a tidy application."
Uhm... I already do half of these things with make, but they're all trivial.
"No offence, but would like to see your little makefile handle a large project; with hundreds of programmers with different OSes, IDEs and subprojects."
make has been doing this for years...
"Sometimes a wheel comes along that is a significant improvement on previous ones."
I think you overestimate it's improvements, is all.
Actually, I wondered why you were being so defensive until I realized that I forgot the smiley at the end of the last post. I don't really care what you use to compile your stuff, just don't force me to use it.
*shrugs*
:-)
That's nice and all, but the stuff javac finds is the easiest kind of bug to kill. Heck, once you've been developing for a while, you tend to not make those mistakes anyhow. And it's not really much of a time-saver for me, since compilation from inside emacs will take me to the line I goofed.
I just don't get all the fuss.
Honestly, I tried eclipse. But not for anything too serious because it wanted to move all of my source files to make a project... That's irritating, to say the least.
What's so wrong with the old ways? Before you get carried away about how "powerful" something is, consider what you need. Here's a Makefile excerpt:
:
Search.class : Search.java
${CC} -classpath ${CP} Search.java
Easy. Every developer's system should already have `make`, so there's no need for other dependencies or learning some crazy IDE just to compile some Java. Heck, every IDE and text editor should be able to run `make`.
The following makefile target is about as advanced as I needed, and it's mostly scripting. It's a little something I added when we got some programmers involved in the source using fancy IDEs that couldn't even format multi-line statements correctly. So I use emacs to fix it for them:
indent
for f in `ls *.java`; do \
emacs --batch -l ~/.emacs -l ${TOPDIR}/batch-indent.el --eval "(batch-indent \"$$f\")"; \
done;
New ways are all fine and dandy until you realize you just reinvented something another programmer has been doing for years. He'll probably laugh and mumble something about "those kids these days."
Oh, man. It's too late for this one.
Aight, I'll take a stab...
:-) Check out pound:
You'll need a hardware SSL loadbalancer, with redundancy:
http://www.coyotepoint.com/e450.htm
(Two of those).
You'll need at lease two web servers with CPU and RAM. The requirements on these boxes really depend on the app. I'd make them dualies at least, with fast Xeon processors (Good bang for the buck). A couple gigs of ram each. You can add servers to the load balancer later if you need to. Disk doesn't really matter, but I'd use a SCSI mirrored root volume for reliability.
The database needs to be redundant, and since you think it'll be the bottleneck, an Oracle RAC setup would seem to fit your needs. I really don't like Oracle from a developer stand-point, but two big servers with Oracle running on raw disks for performance is a tough combo to beat. Expensive and long on the setup and install, though.
With all of that, you'd have a large initial investment, but something that would grow with your needs. You could add new apps to this setup later on, as well. However, if you needed to run this on the cheap, the Linux Virtual Server project does a lot of this with simple Linux boxes.
If this is too expensive, the first thing to take out is the hardware SSL. I included it because I want them, not because I have 'em.
http://www.apsis.ch/pound/
A couple Linux boxes with failover setup and you've saved a good 40-70 grand. Requires some expertise.
I call bullshit. :-)
By pissing off Diebold, you'd anger a good deal of the most powerful people in the world. The people who control the combined forces of the FBI, CIA, NSA, the military, and everything in between.
And you'd just blackmail them (and commit a felony)? At best you could hope to blow the whistle and create a scandal, but your career would likely be over. That'd be very noble, but not really on par with "by the balls."
s'alright. I'll buy games on the PS2 now and run them smoothly on the PS3 later. You can buy them over again. :-)
Personally, I have never used or considered using ActiveX since it only runs on Windows. What I know is it's a program, usually Visual Basic cab file, running within the browser. There have been several security problems, mainly stemming from the fact that once running, it has programatic access to the whole computer.
:-)
:-)
Other than the security issues, and that it only runs on Windows and within IE, I understand it's generally a pain to work with and debug. But it does allow you to run programs on the client and use normal Windows widgets in your design. Painfulness is measured differently by me than somebody who programs for Windows. I imagine they would disagree.
Somebody will correct me if I'm wrong on the ActiveX details here, I'm sure.
XUL is meant for addressing the same problem -- bad interfaces on the web, but it takes a drastically different approach. The dialogs are described by lightweight XML files that are pretty painless to develop. The client programming is done in Javascript, which is not as bad as it sounds. The main problem Javascript faces is cross-browser support, which is negated by only using gecko. There's also a decent Javascript console which make it a lot easier to fix script errors in Mozilla than in IE.
The main advantage is everything is still done on the server, only a little user interface junk is left to the client to handle in Javascript, which is arguably where it belongs. You'd do the same in a normal webapp, write html and use Javascript to manipulate objects for a better user experience.
Also, I've seen far too many ActiveX programs that do database access from the client, for example. Typically, there's no security or verification of who's doing what at that level, a difficult thing to get right in any client. Often times you can take the ActiveX object and use it's own objects to access the database and change whatever you like. XUL leaves all of that up to the server which makes it easier to manage and more difficult for bad programmers to leave gaping security holes.
Anyway, there's no 'trusted' environment. All companies should prevent internal users from abusing the system.
Uh... I think you misunderstood what all of this is about. Firefox *and* Mozilla already use a XML format called XUL for their interfaces. It's already in both of them, and there's no reason to change the browser to support any of the uses mentioned.
.xul file and away you go.
Heck, you don't have to install XUL to get it working, just browse to a
-1, Ignorant
You're absolutely right. My company, before I started, was using several Windows-only applications. One major DNA-based app died off when the software company was bought-out (which I've rewrote for the web, like you mentioned) and others have been moved to web-based services. That wasn't even at our prodding, soap and xmlhttp are getting huge in the Financial Industry.
:-)
I've recently started in on a XUL app (though not PHP and MySql -- JSP, LDAP and PostgreSql since we had that architecture). I think if the XUL interface designer gets some more polish and support for IDE functionality, this platform could be huge. Firefox is just getting started, but as it becomes popular this could be the next popular wave of free software usage.
Where I think you're wrong, though, is the amount of ActiveX/DNA apps companies are still locked into. They're shrinking rapidly. We've seen a large number of them get converted into webservices. At least in Banking, the software vendors seem to have realized we mostly all have our own internal apps anyway, and we don't want to admin yet another client install. I'd wager that's the same thing happening in other industries, albeit a bit slower. Banking is often among the first to implement new tech.
The main point is that admins are less likely to buy and implement anything that's not web-based since it means more work for them, so many apps are being rewritten. So far, that hasn't meant increased ActiveX usage, since banks are pretty hard-core about security and like to keep it turned off.
There's only one app that I can think of where there's not much of an alternative: ACT. I hate that program, but the sales people are addicted to it.
Yes! Holy cow, was I surprised to see the Collegian cited in anything outside Fort Collins. Sweet. :-)