|
I had a chance to walkin to Axis Bank branch in the Chennai suburb on Saturday afternoon. The connectivity to the server seemed to be weak and hence the personal bankers attending to the customers even warned to each customer of the little delay and then were trying to maximum solve the queries as much as possible.
When my turn to the Personal Banker came and she was about to logon to the Menu Interface to my account in the application, she got a message
'java.lang.IllegalStateException' and that seemed to be an indication of Connection dropped again. Isn't it a true WTF that without quality testing the banking product has come into deployments? And interestingly, after a few tries it logged on to present a 'Maximum License Reached' but the app was still functioning.  The logon was showing the name of the application as Finacle.
This comes close to the heels when we discussed another Banking Issue [^]
sometime back regarding a bad database design of storing customer data in multiple tables.
-- modified at 6:01 Monday 29th October, 2007
|
|
|
|
|
Vasudevan Deepak Kumar wrote: Axis Bank branch
OOPS. I thought they have a good system. Their Iconnect facilities are fair enough.
|
|
|
|
|
N a v a n e e t h wrote: they have a good system
They do. They have a good customer care too. It is that WTF Finacle which is screwing things all along. Even in ICICI bank infinity which is powered by Finacle, when you logout it gives a JavaScript error since they use a ExecWB (Web Browser Object) to close the browser window, which is no longer supported.
|
|
|
|
|
Vasudevan Deepak Kumar wrote: It is that WTF Finacle
By infosis Right ? My friend is into it's implementation department, and he said it's a superb product.
|
|
|
|
|
N a v a n e e t h wrote: he said it's a superb product
Not to offend. But as long as the product or the application is in our cosy comfortable lap, it would sound and resemble that way. But there are integration paranoia, which any application should pass this litmus test to prove itself of its capabilities to the world. 
N a v a n e e t h wrote: infosis
Infosys and its Stock Symbol is INFY right?
|
|
|
|
|
When I belive a system is good tested and more or less secure, than it should be a bank system, shouldn't it?
So seems to be my fault .
Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|
|
Fatbuddha 1 wrote: system is good tested and more or less secure, than it should be a bank system
True. That would be a very optimistic view.
Fatbuddha 1 wrote: seems to be my fault
Not necessarily. But those developers who brought out the buggy system had thier thought process the other way around -- Banking system is one of the systems. 
|
|
|
|
|
One of our ASP.NET web applications is supposed to use a java web service developed by another team. However, the service returns session errors about 50% of the time in development environment (credit to the jave team, at least it is failing at a consistent rate ). But it works fine in formal test and production environments.
Stupidity: As it turns out, when this java web service is called, it makes two calls to another java web service to do the work, and the second java web service is load balanced. The first call establishes a session with the second java web service on one of the two load balanced physical servers, the second call tries to use the established session, but 50% of the time the request landed on a different physical server, hence the session error. In formal test and production environments, back-doors are open to ensure that request to the second java web service is made directly to one physical server and that's why it does not have the session error.
Stuburnness: We requested that if the java web service can't be fixed to work properly, a similar back-door should be open in development environment so that we can get some work done. The answer is NO, instead we get a lecture about design principles, best practices, and beans/factories/containers/layers, etc. In other words, we are not worthy of using the java web service.
To this day, we are disabling the code to call to the java web service in development environment, hoping everything will be fine in formal test and production environments.
-- modified at 10:16 Wednesday 24th October, 2007
|
|
|
|
|
That’s nuts, whatever one group needs to make it work, so does the other group. If the management does not agree, then they should insure that the group responsible fixes the problem so the second group never sees it. In other words, they should have tested it under the conditions which group 2 requires before passing it on to them. That is best practices and et cetera, as not doing so waste everybody’s time and cost the company time and money.
I hope it works out, but not being able to test properly during the development phase is a very bad thing.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
nice problem
it is not big problem i have a great solution for this problem.
use Entry exit point when it call another web service.when it'll call load balance service then use Exit point and here save all information regards to the session.
when it connect previous one then use entry point here invoke all information regards to the session. useing above idea where the session started.it'll save on user M/c then we dont need to maintain session in server end.
|
|
|
|
|
[rant]
Here's the setup of an "unidentified" application:
For some reason, the developer didn't want to code in the language to which he was assigned, so the first thing that he did was create an entire generator that allowed him to generate the "other" language so that he could continue to program in the language of his choice. The resulting application is so "objectified" that the object model is several layers deep, and in order to find a "Save" command, I have to wade through 20+ pages of documentation describing his monolithic object model. The irony of it all is that it's nicely structured, it has all of its unit tests, and it also has plenty of documentation. In all, I'd say the codebase is about 30k lines, which isn't too terribly large.
There is, however, just one problem: I did the same project in less than 2k lines of code!
It's a bloated masterpiece!
[/rant]
Has anyone else ever run into this scenario?
|
|
|
|
|
Philip Laureano wrote: Has anyone else ever run into this scenario?
MFC?
|
|
|
|
|
J2SE?
I kid, I kid! 
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? 
|
|
|
|
|
Naw, he mentioned "nicely structured".
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
Save an Orange - Use the VCF!
VCF Blog
|
|
|
|
|
STL? ATL? COM? DCOM? ... 
|
|
|
|
|
Nope! But my first professional programming job was to write an application in less than 2 weeks, because the previous programmer, who was writing it in assembly over a 6 month period, left the company along with all the code. I brought in my libraries, QuickC compiler, and wrote it in C, it worked well given the time frame.
I occasionally write code generators, but only when it is required to eliminate wasting my time by having to hand code something that can be automated. Point, click, verify, and generate. That way a non-programmer can handle the creation, and I only have to verify it, before and after the code generation.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
Actually, yes!
In my college days, I was taking an AI class and one of my fellow students got around a language requirement for one assignment by writing a LISP interpreter in Prolog just so he could do the actual assignment in LISP (or maybe the other way around, I don't remember -- that was almost 20 years ago)
|
|
|
|
|
Probably PROLOG interpreter for LISP: the reverse would be extremely difficult. A number of these have been made. The best Common LISP implementation around is AllegroCL (still among the most powerful platforms, esp. with its unmatched AllegroCache). AllegroCL has an extension called AllegroPROLOG, which is implemented on top of AllegroCL in such a way that the programmer can mix LISP and PROLOG code freely, while the PROLOG code is compiled into LISP code and integrated properly. Pretty nice for certain applications, notably Artificial Intelligence, for which AllegroCL is probably best.
-Nick P.
|
|
|
|
|
Reminds me of a job I did MANY years ago (when I was a fresh out of college 'grammer). Of course, my reasons were actually legitimate.
We were using Turbo Pascal (TP3 I think, but not sure, circa 1986) to develop the project and I discovered that TPs keyboard interrupt routine would occassionally drop characters if you typed fast enough. So, I wrote a new keyboard interrupt routine in 8086 assembler, hand assembled it, and put it in as inline binary code (TP had a way to do that). Worked like a charm.
|
|
|
|
|
the handler used by the IDE or the one used by applications it built? I used TP6/7 in HS during the mid/late 90s. I never noticed a problem in the IDE, and IIRC apps built in it used the DOS handler by default. OTOH I'd replaced the one for DOS with a 255 char buffer instead of the paltry dozenish MSes used. For most of my larger apps I used a custom handler that supported multiple simultaneous key presses. I grabbed the ASM for both off the web though instead of writing my own.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
The one used by the apps it built... And the buffer was the problem. Boy is thi staking me back to that project 20+ years ago...
I was a new developer and just knew that I needed to rapidly catch the keystrokes for processing. There weren't any standard "input" type fields on the application as it was a real time graphing system for statistical process control that processed data coming in through the keyboard buffer from various data-collection devices. Being a public/purchased application, we couldn't guarantee the devices would be configured with 40ms delays between simulated keystrokes. This was in the day when user's who bought the software put requirements on the software, not the other way around.
There were several modules to the application.
One was the device interface which would capture the input and push it into the keyboard buffer. The requirement was that the floor users had to be able to upload this data as fast as possible as well as be able to do near real-time input from the collection devices.
The second module also ran in the background and collected that data from the keyboard buffer and wrote it to the datastore (a custom designed fixed-length flat file system with a unique indexing algorithm written by the senior developer). He was having a hard time with the buffer overflowing on large uploads and losing data, so he asked me to research alternatives. I came up with a cheap custome keyboard handler with a large (8K I think) buffer which would hold everything the largest device we supported at the time. At the same time, it sped up the processing of the data as the TP-based keyboard handler would type into a text field at a very slow paste. I could type 70 WPM at the time and I could make the simplest input field drop characters.
The third and final part would continually update the various control graphs from the flat files. I did plenty with that eventually as well, but that's another topic.
This was 1986 and the PC/AT was the latest and greatest thing. Windows 286 wasn't even dreamed of (much less 3.0, 3.1, Workgroups, or the future OSs) and the Mac was viewed as a "toy" for graphics designers and the like, not a serious machine for floor production systems. Instead, factory floors had ultradurable (and super-expensive for their day) PC or XT 8086/8088 based computers from Compaq or IBM. In short, creative "get it done" solutions that could do things quicker and with little overhead were the best. I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
-Draugnar
|
|
|
|
|
Draugnar wrote: I think the assembler code took less than 1K so the whole thing was under 9K and our entire package could run on a 512K XT very reliably.
The handler or the application? IIRC the big buffer handler I'd used took less than 1k ram. I actually have the HD from my 486 sitting around somewhere, unless it suffered bitrot over the last few years I could probably still boot it if I actually wanted to.
--
If you view money as inherently evil, I view it as my duty to assist in making you more virtuous.
|
|
|
|
|
The handler module took 1K on disc and 9K in memory (adding in the 8K for the buffer). The whole application took significantly more (it's been 20+ years and my memory fades now that I'm in my 40s), but still ran on the 512K XTs that had been spec'd by our beta client (who got the final app at a greatly reduced price over the later retail clients).
-Draugnar
|
|
|
|
|
The most interesting part of the project was the hand assembling. The Microsoft assembler put in header info for the linker that I didn't want as it was going in as inline binary, so I sat down with the 8086 Assembly manual and hand assembled it so I had just the code used by the routine. Having taken C+ (not C++) and 360/370 Assembler in college sure made that job a lot easier.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
