Looking For Direction
in [Java Programming]
|
From: Arved Sandstrom on 11 Jun 2010 05:55 JC wrote: >> He may not be a DBA, but if has been writing SQL statements for the >> app then he would know some of Oracles ways of doing things. >> >> Arne >> > > I dream in SQL ... :) > > Even though I'm not a DBA, from time to time I have to do DBA oriented > things. Since the system is not highly sophisticated this is never been too > much of a problem. I'd say the most important thing I do along these lines > is monitor the size of the tablespaces, how fast they are growing. Maybe a > few times in the beginning I had to resize them; but I pretty much have a > handle on it now. By law we only have to keep ten years worth of data. So > every night I have a routine that deletes anything older than ten years > (actually I go ten years and six months just to be safe). We started doing > this (deleting old data) about a year or so ago. It helps keep the size of > the database more stable (except whenever we get new contracts that are big > clients which has happened twice ... once with the state of Alabama and more > recently with West Virginia). Anyway, what I worry about is with the > deleting and adding of data on a consistent basis whether something funky > will happen some day like file corruption, fragmentation, etc. Things which > I really don't know how to fix of have any experience with. > -JC I should note, I certainly wasn't casting any aspersions on you by emphasizing that you said you're not a DBA. Neither am I. I can get basic DBA things done on a number of RDBMS's like Oracle, SQL Server and PostgreSQL, and for the databases you use I suspect you're at the same level as myself. I was simply considering the fact that I myself don't have a great deal of time invested in learning how to do these basic DBA tasks. Also, there are a lot of resources available for any de facto DBA, for almost any widely used RDBMS. So switching from one to another, and acquiring the basic skill set that you have for your version of Oracle on another RDBMS, is not a large investment of time, IMO. To reiterate, I am _not_ suggesting that it's a trivial thing for a _true_ DBA on RDBMS #1 to acquire the equivalent skills on RDBMS #2. AHS -- It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. -- Nathaniel Borenstein
From: Arved Sandstrom on 11 Jun 2010 06:20 Alessio Stalla wrote: > On Jun 11, 12:00 am, Arne Vajh�j <a...(a)vajhoej.dk> wrote: >> On 10-06-2010 11:03, Alessio Stalla wrote: >> >> >> >>> On Jun 9, 11:19 pm, "JC"<jjcarde...(a)hotmail.com> wrote: >>>> For the user interface I am thinking of something that is >>>> integrated with a web browser. >>> In addition to what everyone else said, I'd like to concentrate on >>> this point. Are you really sure you need a web-based interface (i.e., >>> do you really need to expose your application to potentially anyone >>> anywhere), or are you considering it just because it's today's trend >>> to build web applications? >>> In my experience (2+ years in JSF + some minor projects with Struts) >>> web applications often face an additional layer of complexity than >>> client-server applications, and are generally limited in functionality >>> (by the browser and by the stateless nature of the HTTP protocol). >>> I think JSF especially is a very bad choice. I used the ICEFaces >>> implementation, which adds its own host of problems, but JSF in >>> general is terribly complex, and has a fundamentally bad design. >>> Imagine someone proposed to you, for a client-server application: >>> "hey, let's do this cool thing, let's keep *all* the GUI state on the >>> server and ask for it *each and every time* the user interacts with >>> the GUI"... you would say that's crazy, wouldn't you? Yet it's >>> precisely what JSF does >> That is what all non-AJAXified web apps does. > > No. Most web frameworks reconstruct the page for every request, and, > if applications are designed with a bit of cleverness, they only keep > in session the minimum amount of state necessary to reconstruct the > view. They don't keep in memory all the labels, all the CSS classes, > all the component ids, ... like JSF does. That could conceivably become an issue if a _large_ number of simultaneous (or near-simultaneous) requests caused a large number of views to be rendered at the same time, sure. On under-performing hardware and software, moreover. The scale of the JSF apps I work with is such that there are several hundred users at any given time, requesting HTML/Javascript/CSS rendered from fairly complex JSF, _and_ requesting new pages with rather high frequency besides, and in all normal use that I can recall over the past few years the servers don't even blink at this particular chore. The OP knows his own application best. But to me it doesn't sound like the use of JSF is going to be a problem for him in this regard. >> You can do AJAX with JSF if you want to. > > You can, of course. I have only used ICEFaces which does a terrible > job at it, but maybe other AJAX JSF implementations are saner. With all due respect it also depends on how you use ICEFaces. I've used it a fair bit, and my rule of thumb is to use ICEFaces components only when I actually need them. Which is not often. I don't use them for every component on a page, for starters. To the degree that I have used ICEFaces I myself did _not_ have a terrible experience. There, that's 2 opposing datapoints. >>> (and ICEFaces exacerbates the problem by >>> forcing everything to be AJAX, even stuff that could be client-side >>> only, like help tooltips). >> AJAX is by definition running client side. > > No, AJAX by definition is asking stuff to the server asynchronously. > Why showing a help tooltip, or opening or closing a date selection > popup, should ask the server for data? > >>> Then, there's the complex and strict life >>> cycle, >> Just learn it. > > I did learn it. I also endlessly fought against it when it proved to > be too inflexible. How demented it is that to *empty* a form I have to > generate an "immediate" event and cycle through the tree of components > in the view to empty them *by hand*? And that I have to jump through > hoops because "emptying" a component can mean different things for > different components? Again with all due respect, it sounds to me like you were not working with JSF - it sounds like you had expectations and pre-conceptions and they didn't get met. I haven't used a single web framework in any environment where I didn't have to adapt my thinking to it, rather than the other way around. Every web framework has had blurbs and documentation where they claim that they make it easy for the page author and backing code implementor to write in a natural way - well, take that with a pound of salt. I haven't used any where that's the case, and I don't ever expect to. As for your stated use case, well, I haven't ever - not in several years of intensively using JSF - ever cleared out a form the way you describe. I've certainly read blog articles where people discuss doing it that way, but I've never done it like that. Myself I simply blow away managed beans if I have to. >>> the macroscopic mistakes in the class hierarchy, >> If we would ditch all API's where someone did not like something, >> then there would not be many API's available. > > Replicating isDisabled on all components rather than declaring it once > on UIComponent and inheriting it is an objective mistake. And it's not > just isDisabled, other methods are like that. You have to resort to > reflection to do even simple things uniformly for all components. > State saving is also cumbersome and error-prone, but I can live with > that. Creating components programmatically is unnecessarily hard. > Parsing dates by default forcing GMT timezone is wrong. Etc. etc. > > Alessio I figure everyone's experience is different. I've certainly had issues with JSF 1.x (and most if not all of them have gotten addressed with JSF 2), but those issues don't exactly sound like yours. Generally speaking I've found it fairly easy to get the pages I need with JSF, my own Javascript, and CSS, and the right code in the backing beans, and the pages I produce are handling some fairly complex busness situations. If I had any complaints about API shortcomings in J2EE then JSF wouldn't be tops of the list. It might be #4 or #5 at most. For me it simply doesn't cause many problems. AHS -- It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. -- Nathaniel Borenstein
From: Alessio Stalla on 11 Jun 2010 06:30 On Jun 11, 5:11 am, "JC" <jjcarde...(a)hotmail.com> wrote: > >> For the user interface I am thinking of something that is > >> integrated with a web browser. And of course some sort of interface > >> between the two. > >Why would you want that? A proper Swing GUI gives you more freedom than > >any browser based technology. If deployment is no problem, and with > >Webstart it isn't, there is no point in using a web based GUI for a system > >which is not intended to run on the web - and with webstart even that > >would be no problem. > > Right now clients (physicians, clinics, hospitals) send test samples along > with a "requisition" which includes demographics, patient history, insurance > info, etc. We have a data entry clerk that enters this into the system. I > was thinking somewhere down the line if we had a web-based interface the > clients could fill in that info electronically instead of writing it on a > form and sending it to the lab where someone has to enter it. I think it > would save money but I reckon someone would lose their job. Unless the forms you are describing are all the GUI of the application, there's really no reason to turn all the application into a webapp for a just a few forms. You can expose some selected forms via the Web, but keep the most of the application as a client-server app. That way you get the flexibility of the web when you need it, and you're not hampered by its limitations when you don't need it. If you want you can even share the server (the physical machine, and the application server where the app runs) between the webapp and the client-server app; of course you have to be aware of the potential security risks, but that's a concern that you always get when you expose some services to the outside world. Cheers, Alessio
From: ilan on 11 Jun 2010 06:57 Arved Sandstrom <dcest61(a)hotmail.com> writes: > ilan wrote: >> Arved Sandstrom <dcest61(a)hotmail.com> writes: >> >> <snip> >> >>> The way Mono is moving along that's not strictly speaking true. In any >>> case, being "locked into" a Windows-based network is not exactly a >>> liability, not now and not for a few more decades. >> >> Being locked into a Windows-based anything is liability. It is. And >> in this case its simply not necessary. > > You know, being locked into a Linux distro or a flavour of UNIX is > just as much of a liability. I gotta tell you, I fail to see how being > "locked into" Windows is a problem. I know that Java does not lock you into a Linux distro or a flavour of UNIX. Java and its eco-system is proven as cross platform; and .Net is not. Being locked into something is a constraint. And an unnecessary constraint is a liability. > >>> As it is, the majority of fellow developers and clients that I deal >>> with do J2SE/J2EE on Windows. >> >> So? How did the developers and clients you deal with suddenly become a >> symbol of the entire wired world? Its your world. That's ok. But its not >> everyone. >> >>> Every job I've had there's always been a fair bit - often a majority - >>> of other applications that have been on Windows. >> >> Yes. Every job *you* have worked in. So what...? Really. > > My statement was anecdotal, but I'm prepared to guess - damned if I > know why I believe something this outlandish - that a whole bunch of > people out there...maybe even a majority...use Windows. But if you > think different that's your prerogative. Here is something factual. http://en.wikipedia.org/wiki/Web_server http://news.netcraft.com/archives/2010/01/ Vendor Product Web Sites Hosted (millions) Percent Apache Apache 111 54% Microsoft IIS 50 24% Igor Sysoev nginx 16 8% Google GWS 15 7% lighttpd lighttpd 1 0.46% -- ilAn
From: rossum on 11 Jun 2010 07:52
On Thu, 10 Jun 2010 06:17:52 -0700, Patricia Shanahan <pats(a)acm.org> wrote: >JC wrote: >... >> The equipment at the lab is antiquated. I would say the server is pushing >> twenty years old. The network O/S is an unsupported version of Netware (5.0 >> I think). The version of Oracle, also unsupported, is 8.0.1 and came free >> when they did the Netware upgrade eleven years ago. Although we do nightly >> backups I have to say I probably wouldn't know what to do should a restore >> be needed. >... > >The backup issue seems *very* serious to me, something you should fix >ASAP regardless of any changes to anything else. If you do not know what >do to if a restore is needed, you are presumably not testing your >backups by doing restores. How do you *know* your backups are working? > >I have seen very serious problems in a situation in which everyone >thought some files were being backed up, and didn't find out there was a >problem in the back up process until the files were lost in a disk failure. > >Patricia What she said. It is a conceptual error to call it a "backup", it is better called a "restore". If you cannot restore it successfully then it is useless to you. You have to test that the restore actually works. rossum |