Who the hell writes production software on version 0.1 of anything? I bet the business is just delighted that you have to rewrite these systems because the shiny new thing the engineers wanted to use was totally unsuited to the task. Is anyone accountable for that brain dead decision?
Compared to web, it has advantages that the original poster enumerated, as well as:
- support for hotkeys and shortcuts (especially big for manual data entry/call centre users)
- ability to easily rescale + resize to fit into available screen real estate.
It's simple for a terminal emulator to scale down fonts when the window is resized. Try that with your average GUI or web page.. not to mention component layout issues when dealing with GUIs. This may sound dumb, but it can be a big issue for call centres having to juggle multiple apps but with only one physical screen.
- simplified deployment (yes, even simpler than web) - no issues with browser versions, plugin conflicts, etc etc.
- SPEED! Compared with the latency of your average web front-end.
Issues like this really add up to a big difference for apps that are used intensively.
I work with a large, legacy codebase - about 2 million lines of code, 600 tables. Some bits are nicely written, some aren't. Concepts such as dependency injection, seperation via interfaces etc are not prevasive, so traditional unit testing approaches of mocks or HSQL are not useful (in fact I find they do not scale for 'meaningful' tests anyway).
So you have this legacy code base - you want to make changes, but how can you validate the result? One approach is to compare database states - one from a known good codebase, one from a modified codebase. DBUnit can be tremendously useful here - this is what I've done (perhaps too complex for explaining on Slashdot):
Create a common Unit Test base class that extends DBUnit's DatabaseTestCase. It will:
a) receive a list of modified table names from the concrete test class
b) if a system property is set, export a pristine copy of these tables prior to running the test - 'reference data'.
c) execute the use case (register a user, perform a transaction, whatever) - this just makes a 'blind' call into the
code proper.
d) if a system property is set, export the modified table data ('known good results')
The idea is you run this test twice:
1) With the original codebase, with result exporting enabled to generate known good results.
2) With the codebase under test - the results generated will be compared against known good results and DBUnit will flag any differences. You can get it to ignore stuff like sequnces,dates that will differ between runs.
The reference data generated in (b) is reloaded prior to running the test second test, so you start from the same point. Each concrete test class just has to:
* figure out what tables change within the test * provide the test code itself
Everything else is managed by DBUnit - exporting/importing datasets, comparing datasets, etc.
Do you really find a performance difference with 'final' ?
I'd be interested to hear your experiences here. I advocate 'final' as an aid to expressiveness, but understood the performance benefits were minimal these days.
JProfiler just works, and you get the information you need really quickly. I'm not a shill, just a fan. I've introduced it to my new employer, and the developers now go through a compulsory JProfiler session before any significant changes get committed. We're working in a large, mostly legacy code base, where the impact of changes isn't always understood. Just ordered another 3 floating licenses. Yes, it's about AUD 3000, but that is repayed sooooo quickly.
+1
Of all the profilers I've used, I have found this to be the most intuitive. This is a really important attribute. A lot of the time, this kind of software gets used to sort out a super-critical production/customer issue, and developers don't always have the luxury of time to figure out the quirks and metaphors behind a product.
Exactly. They'll have to go after TopLink as well, which certainly predates 2000. Hell, I was working with a commercial framework called 'Persistence' in 1997 that used a similar approach (albeit in C++).
From an organizational point of view (be it a company, a government department, whatever), while it's true that a monoculture introduces security risks, a 'polyculture' introduces other problems - complexity in terms of patch administration, help desk, staff training, desktop imaging, license compliance, etc etc. This is precisely why organisations generally standardise on a single product + version - regardless of the underlying format.
Switching to an open format (eg ODF) does not imply a polyculture, it just doesn't preclude it. Chances are that a given organisation will standardise on a software tool to work with that format; they'll still be a monoculture and (theoretically) subject to the same risks.
Having said all this, I agree on the statement that publically owned documents should avoid proprietary formats. That's a no-brainer.
I remember the days - 40+ first years bringing a Sparc box to its knees. Didn't help that the Eiffel compiler actually got the job done by doing a translation to C, followed by compile + link-against-the-universe.
I pulled 2 all nighters in a row trying to get that first project done. Cup after cup of vended coffee, falling asleep in front of vi, waking up in front of vi. Finally going home on the train, falling asleep and waking up in the middle of nowhere (well, Beecroft).
Have you identified what your requirements are from a reporting tool, be it open source or commercial? Your definition of 'prime time' is totally dependent on this
- who will be writing the reports (techies, business folks, both)? - what layout and formatting capabilities are absolutely needed? - any really big reports? performance may be an issue - what are the security needs - authentication, visibility, auditing, etc? - do you need overnight automated report runs? - what about bursting (automatically splitting a report into sub-reports based on department, product type, whatever)? - do you need to integrate with custom developed software? what language+platform, etc?
The first point is particularly important - if business staff want to dolly up simple adhoc reports, then this will seriously narrow down the open source field pretty quickly.
Slashdot Mirror
They didn't do the needful.
Yes, these posts on Slashdot will wait for no man... can't these people see I'm busy?
The LINQ syntax does that. It's not just a fancy way of iterating over an in-memory collection.
A sure sign of any well balanced, fair and unbiased comment are when all citations 'backing it up' are links to the poster's blog.
Who the hell writes production software on version 0.1 of anything? I bet the business is just delighted that you have to rewrite these systems because the shiny new thing the engineers wanted to use was totally unsuited to the task. Is anyone accountable for that brain dead decision?
Thanks! That's all I wanted. Good night. P.S Could you come work in my office?
Compared to web, it has advantages that the original poster enumerated, as well as:
- support for hotkeys and shortcuts (especially big for manual data entry/call centre users)
- ability to easily rescale + resize to fit into available screen real estate.
It's simple for a terminal emulator to scale down fonts when the window is resized. Try that with your average GUI or web page.. not to mention component layout issues when dealing with GUIs. This may sound dumb, but it can be a big issue for call centres having to juggle multiple apps but with only one physical screen.
- simplified deployment (yes, even simpler than web) - no issues with browser versions, plugin conflicts, etc etc.
- SPEED! Compared with the latency of your average web front-end.
Issues like this really add up to a big difference for apps that are used intensively.
I work with a large, legacy codebase - about 2 million lines of code, 600 tables. Some bits are nicely written, some aren't. Concepts such as dependency injection, seperation via interfaces etc are not prevasive, so traditional unit testing approaches of mocks or HSQL are not useful (in fact I find they do not scale for 'meaningful' tests anyway).
So you have this legacy code base - you want to make changes, but how can you validate the result? One approach is to compare database states - one from a known good codebase, one from a modified codebase. DBUnit can be tremendously useful here - this is what I've done (perhaps too complex for explaining on Slashdot):
Create a common Unit Test base class that extends DBUnit's DatabaseTestCase. It will:
a) receive a list of modified table names from the concrete test class
b) if a system property is set, export a pristine copy of these tables prior to running the test - 'reference data'.
c) execute the use case (register a user, perform a transaction, whatever) - this just makes a 'blind' call into the
code proper.
d) if a system property is set, export the modified table data ('known good results')
The idea is you run this test twice:
1) With the original codebase, with result exporting enabled to generate known good results.
2) With the codebase under test - the results generated will be compared against known good results and DBUnit will flag any differences. You can get it to ignore stuff like sequnces,dates that will differ between runs.
The reference data generated in (b) is reloaded prior to running the test second test, so you start from the same point. Each concrete test class just has to:
* figure out what tables change within the test
* provide the test code itself
Everything else is managed by DBUnit - exporting/importing datasets, comparing datasets, etc.
+1 for subversive
Another important point - Polarion (the authors) recently submitted a proposal to make subversive a standard project under eclipse.org
http://www.eclipse.org/proposals/subversive/
Do you really find a performance difference with 'final' ?
I'd be interested to hear your experiences here. I advocate 'final' as an aid to expressiveness, but understood the performance benefits were minimal these days.
JProfiler just works, and you get the information you need really quickly. I'm not a shill, just a fan. I've introduced it to my new employer, and the developers now go through a compulsory JProfiler session before any significant changes get committed. We're working in a large, mostly legacy code base, where the impact of changes isn't always understood. Just ordered another 3 floating licenses. Yes, it's about AUD 3000, but that is repayed sooooo quickly.
+1 Of all the profilers I've used, I have found this to be the most intuitive. This is a really important attribute. A lot of the time, this kind of software gets used to sort out a super-critical production/customer issue, and developers don't always have the luxury of time to figure out the quirks and metaphors behind a product.
Interesting question. My guess is they view Redhat as the softest target from all the candidate targets that actually have cash.
...Economics.
Exactly. They'll have to go after TopLink as well, which certainly predates 2000. Hell, I was working with a commercial framework called 'Persistence' in 1997 that used a similar approach (albeit in C++).
The new EJB model is strongly influenced by Hibernate. Gavin King (founder of Hibernate) was on the expert group.
From an organizational point of view (be it a company, a government department, whatever), while it's true that a monoculture introduces security risks, a 'polyculture' introduces other problems - complexity in terms of patch administration, help desk, staff training, desktop imaging, license compliance, etc etc. This is precisely why organisations generally standardise on a single product + version - regardless of the underlying format.
Switching to an open format (eg ODF) does not imply a polyculture, it just doesn't preclude it. Chances are that a given organisation will standardise on a software tool to work with that format; they'll still be a monoculture and (theoretically) subject to the same risks.
Having said all this, I agree on the statement that publically owned documents should avoid proprietary formats. That's a no-brainer.
I hear ya. More jaunt needed. Nvidia Prism Intel Buccaneer AMD Tyrano
I think you need to cut down the number of blogs you read..
Richard Dawkins, Climbing Mount Improbable. pp 138-197.
UTS Comp Sci grad by any chance?
I remember the days - 40+ first years bringing a Sparc box to its knees. Didn't help that the Eiffel compiler actually got the job done by doing a translation to C, followed by compile + link-against-the-universe.
I pulled 2 all nighters in a row trying to get that first project done. Cup after cup of vended coffee, falling asleep in front of vi, waking up in front of vi. Finally going home on the train, falling asleep and waking up in the middle of nowhere (well, Beecroft).
Have you identified what your requirements are from a reporting tool, be it open source or commercial? Your definition of 'prime time' is totally dependent on this
- who will be writing the reports (techies, business folks, both)?
- what layout and formatting capabilities are absolutely needed?
- any really big reports? performance may be an issue
- what are the security needs - authentication, visibility, auditing, etc?
- do you need overnight automated report runs?
- what about bursting (automatically splitting a report into sub-reports based on department, product type, whatever)?
- do you need to integrate with custom developed software? what language+platform, etc?
The first point is particularly important - if business staff want to dolly up simple adhoc reports, then this will seriously narrow down the open source field pretty quickly.
I'm glad to hear it! Unless you're in Canberra, of course ;)
but what flavour?
lower end, with that much experience? In Australia? I hope you're not anywhere on the east coast.