Well, what was it you liked about it in the first place? Maybe you're not having fun because the language you're using is too low-level and painful. Try a scripting language (Perl, Python, etc.) for some instant gratification. Maybe you're bored by the inane problems in your text books. Real life (as in, a job) often presents more practical and interesting problems, and you may get more satisfaction out of solving a problem that actually needs to be solved. Also, don't believe the rumors about pay. If you turn out to be good at this stuff, you will be paid well.
That's nothing. I remeber running the ORIGINAL Castle Wolfenstein in 2D on my Apple II+. Now that was a great game! It was the first computer game I played that could really keep you on edge the whole time, worried that the SS would show up and kill you. It wasn't about shooting, since shooting would usually get you killed. It was more about stealth. I wonder if this is available for one of the Apple II emulators. I'd love to play it again.
Separating code into MVC layers is a good start, but the real issue is the interfaces between M and V and between V and C. The article really made it sound like these components were coupled pretty tightly.
Not true. There was a clean separation. The model objects didn't have any HTML or display code in them. The templates (views) had no control flow code, only formatting. The controller knew how to pick a view, but not what was in it.
What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.
We had well-defined and documented APIs for all of the components. The hard part in integrating with another system would have been the differences in core functionality, not the interfaces.
Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.
Only to the extent that you can move your J2EE app from one server to another. Every J2EE app uses the basic components (EJB, JSP, servlets, etc.) in its own way. You certainly can't just connect up your warehouse management code to someone else's shipping code without a thorough agreement on the interfaces. Expecting anything more than that is just dreaming.
At that time, neither MySQL or PostgreSQL could handle the load from our traffic. Oracle also provided things we needed like transactions, replication, message queueing, foreign key constraints, etc. Yes, PostgreSQL had some of those at the time, but it had poor performance. Some of these things have changed since then, and it woudl be interesting to see how big PostgreSQL could scale these days.
I would have been very interested in a comparison between their Oracle setup and a PostgreSQL system, given their need for local caching running a PostgreSQL cache on each machine could have been quite a win.
At that time, PostgreSQL performance sucked rocks. Anyway, no RDBMS will be as fast as BerkeleyDB at retrieving a single record with a unique ID.
Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book
The code samples are pseudo-code meant to show the gist of what was happening. If you had decent knowledge of Perl, they would be easy for you to read.
But an application server it is not. Container managed persistance, transactional support, message queues, naming and lookup services?
I think you're over-stating the necessity of these things. Container managed persistence is often a way to replace one short SQL statement with 3 long XML files. Message queues are trivial in a good database (Oracle). Naming and lookup services are need if you're using EJBs, but we didn't need EJBs.
They pulled off clustering for eToys, but it was hardly an out of the box solution.
How do you define out of the box? We didn't do much work beyond the custom programming that was needed for our application. The open source components filled in our anfrastructure needs very nicely. It wasn't a "packaged solution", but it was easier than many commercial packages I've had to use in the past.
I dont understand either why they just didnt use some version of round robin (weighted or whatever) to balance the load...
Round robin DNS does not handle failover. Our load balancer did checks to make sure servers were all okay and moved users from failed servers seamlessly.
We also had a central server, but with a local cache on each machine to improve performance. Although it is possible for one machine to get more than its fair share of sessions, in practice it didn't happen. The load-balancer did a good job of sending new sessions to the least busy machine.
Slashdot Mirror
Well, what was it you liked about it in the first place? Maybe you're not having fun because the language you're using is too low-level and painful. Try a scripting language (Perl, Python, etc.) for some instant gratification. Maybe you're bored by the inane problems in your text books. Real life (as in, a job) often presents more practical and interesting problems, and you may get more satisfaction out of solving a problem that actually needs to be solved. Also, don't believe the rumors about pay. If you turn out to be good at this stuff, you will be paid well.
That's nothing. I remeber running the ORIGINAL Castle Wolfenstein in 2D on my Apple II+. Now that was a great game! It was the first computer game I played that could really keep you on edge the whole time, worried that the SS would show up and kill you. It wasn't about shooting, since shooting would usually get you killed. It was more about stealth. I wonder if this is available for one of the Apple II emulators. I'd love to play it again.
No it isn't. :-)
Not true. There was a clean separation. The model objects didn't have any HTML or display code in them. The templates (views) had no control flow code, only formatting. The controller knew how to pick a view, but not what was in it.
What if eToys had survived the dot-com implosion, and bought or were bought by another company? How well would this system plug into (or be plugged into) any special-needs components of the new system? That's the real acid test of maintainability in the large.
We had well-defined and documented APIs for all of the components. The hard part in integrating with another system would have been the differences in core functionality, not the interfaces.
Maybe these standards exist for perl, and I haven't used it enough in an enterprise context to stumble across them. However, you can't help but stumble across the J2EE stuff when you work with Java. Are these standards perfect? No. Are they complete? No. But they're standards, and that's what makes pluggable components possible.
Only to the extent that you can move your J2EE app from one server to another. Every J2EE app uses the basic components (EJB, JSP, servlets, etc.) in its own way. You certainly can't just connect up your warehouse management code to someone else's shipping code without a thorough agreement on the interfaces. Expecting anything more than that is just dreaming.
At that time, neither MySQL or PostgreSQL could handle the load from our traffic. Oracle also provided things we needed like transactions, replication, message queueing, foreign key constraints, etc. Yes, PostgreSQL had some of those at the time, but it had poor performance. Some of these things have changed since then, and it woudl be interesting to see how big PostgreSQL could scale these days.
At that time, PostgreSQL performance sucked rocks. Anyway, no RDBMS will be as fast as BerkeleyDB at retrieving a single record with a unique ID.
Their code samples given certainly do not represent 'clean and maintainable code' to my eye. perhaps they should invest in a python book
The code samples are pseudo-code meant to show the gist of what was happening. If you had decent knowledge of Perl, they would be easy for you to read.
I think you're over-stating the necessity of these things. Container managed persistence is often a way to replace one short SQL statement with 3 long XML files. Message queues are trivial in a good database (Oracle). Naming and lookup services are need if you're using EJBs, but we didn't need EJBs.
They pulled off clustering for eToys, but it was hardly an out of the box solution.
How do you define out of the box? We didn't do much work beyond the custom programming that was needed for our application. The open source components filled in our anfrastructure needs very nicely. It wasn't a "packaged solution", but it was easier than many commercial packages I've had to use in the past.
Round robin DNS does not handle failover. Our load balancer did checks to make sure servers were all okay and moved users from failed servers seamlessly.
We also had a central server, but with a local cache on each machine to improve performance. Although it is possible for one machine to get more than its fair share of sessions, in practice it didn't happen. The load-balancer did a good job of sending new sessions to the least busy machine.
The technology was successful. The business stuff was not under our control.