Hi
My experience with Javascript is at novice level but on the project I had to use it for,
as a Java developer I couldn't have noticed the following problems:
1. No spell-checking
This is a dynamically typed language meaning that it cannot auto-complete and cannot be type-safe
because you cannot know a variable's type before runtime. You can assign any type to 1 variable after its initialization...
Also it cannot be checked when you wrote "connectoin" when you actually meant "connection" and
you will get a null pointer error only at runtime...
2. Low IDE support
There is no IDE for Javascript. You basically use an editor that can highlight words (Notepad++) .
You make your own discoveries at what helps you fight with writing Javascript code.
3. Debugging is not cool
Today's browsers have integrated debugging tools for web-pages and generally Javascript but nevertheless it's still not as comfortable as setting breakpoints and then following the execution one step at a time.
Those are the few things that got me basically away from Javascripting ...
If you don't agree with my points, feel free to provide arguments against my theory.
Best regards,
Leni Kirilov
Sunday, August 21, 2011
Saturday, August 20, 2011
A diffrent software architecture - LMAX
It was an interesting afternoon to read the article that the famous Martin Fowler had written a month ago.
It's about a different kind of architecture, how it worked and how the software engineers got to that solution of their problems. The project is about processing multiple concurrent orders and the platform had to provide low latency. The team managed to create a system that copes with 6 million transactions per second.
The strange thing is that they do it on a single-threaded application with in-memory database approach (caches).
They have tried other more-conventional approaches like multi-threading and the Actor approach but the performance of the Queue was limiting them, also the need to synchronize threads and interactions between them, context switch at CPU level was drawing performance back.
So they decided to separate input/output and processing into different modules.
Each input event gets unmarshalled and all its required pre-processing (IO operations and credit card verification operations for example) are done before hand and inserted into a the main stream that is processed by the business logic unit.
The team also create special implementations for collection classes so that they use caches better. They processed events not in a Queue approach but with a ring buffer and on it were running several processor modules - one for unmarshalling, one for backup (Journal) and Replicator and finally the Business Logic Processor. They are in a constant race and there are rules that prevent 1 from getting ahead of the other and processing a data field that isn't ready yet. This ring buffer has enormous size (20 million items)
The main idea is that CPU can process fast sequence of operations which are simple (therefore very optimized by the Java compiler), and using in-memory caches (no SQL queries), this could push the performance of a system high.
Also another gain for the team is that they don't have to cope with complex techniques like transactions, inter-thread communications etc...
I think I've just covered the basics of this software architecture approach. If you are interested enough, do visit the original article at -> http://martinfowler.com/articles/lmax.html
It's about a different kind of architecture, how it worked and how the software engineers got to that solution of their problems. The project is about processing multiple concurrent orders and the platform had to provide low latency. The team managed to create a system that copes with 6 million transactions per second.
The strange thing is that they do it on a single-threaded application with in-memory database approach (caches).
They have tried other more-conventional approaches like multi-threading and the Actor approach but the performance of the Queue was limiting them, also the need to synchronize threads and interactions between them, context switch at CPU level was drawing performance back.
So they decided to separate input/output and processing into different modules.
Each input event gets unmarshalled and all its required pre-processing (IO operations and credit card verification operations for example) are done before hand and inserted into a the main stream that is processed by the business logic unit.
The team also create special implementations for collection classes so that they use caches better. They processed events not in a Queue approach but with a ring buffer and on it were running several processor modules - one for unmarshalling, one for backup (Journal) and Replicator and finally the Business Logic Processor. They are in a constant race and there are rules that prevent 1 from getting ahead of the other and processing a data field that isn't ready yet. This ring buffer has enormous size (20 million items)
The main idea is that CPU can process fast sequence of operations which are simple (therefore very optimized by the Java compiler), and using in-memory caches (no SQL queries), this could push the performance of a system high.
Also another gain for the team is that they don't have to cope with complex techniques like transactions, inter-thread communications etc...
I think I've just covered the basics of this software architecture approach. If you are interested enough, do visit the original article at -> http://martinfowler.com/articles/lmax.html
Subscribe to:
Posts (Atom)