Looking For Direction
in [Java Help]
|
Prev: Sending SMS
Next: Urgent DIRECT CLIENT Openings: 1.Websphere Portal - Developer, start date 21st June, 2.ITIM-TAM Analyst in Austin, TX.
From: Arne Vajhøj on 10 Jun 2010 18:00 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. You can do AJAX with JSF if you want to. > (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. > Then, there's the complex and strict life > cycle, Just learn it. > 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. Arne
From: Arne Vajhøj on 10 Jun 2010 18:05 On 10-06-2010 04:32, Tom Anderson wrote: > On Wed, 9 Jun 2010, Lew wrote: >> Arne Vajh?j wrote: >>> x86-64 hardware >> >> Multi-core > > Absolutely no need for either of those. From what the OP says (and, i > guess, what i know about laboratory information management systems), > it's clear his resource needs are modest. Hm. If he decide to use a web app and stick with Java and goes Tomcat and JSF, then I don't think his resource needs will be that modest. > You could run the app he needs > on an Atom. You can get an Atom that is 64 bit and has dual core. I don't think anyone has discussed i7/Xeon/Atom yet. > Not that multi-core x86-64 chips aren't great, and aren't the backbone > of most java server work, and indeed aren't easily and fairly cheaply > availble - they are solid chips which do sterling service. But no need > to sell the guy a thousand-dollar server when a three-hundred-dollar > server will do the job with capacity to spare. You can get a quad core for 200 dollar, so unless an Atom cost -500 dollar, then quad core to Atom can not save 700 dollar. Arne
From: Arne Vajhøj on 10 Jun 2010 18:06 On 10-06-2010 08:51, Tom Anderson wrote: > Don't cut corners, sure. But don't gold-plate either. When you provision > hardware - as when you do anything - you work out what you need, and you > pay for that. You build in some room for manoeuvre. If you're not sure > about what you might need in future, you build in some room for growth. > But since this application has such minuscule resource needs, even a > modest machine provides adequate headroom and room for growth. > > Buy a good-quality machine. But buy the machine you need, not some vast > server that has an order of magnitude more power than you need for the > task at hand. An i5 or i7 based system can hardly be called gold plating. They are damn cheap. Arne
From: Arne Vajhøj on 10 Jun 2010 18:11 On 10-06-2010 17:45, Arved Sandstrom wrote: > David Kerber wrote: >> In article <4c1033b3$0$278$14726298(a)news.sunsite.dk>, arne(a)vajhoej.dk >> says... >> >> ... >> >>> Given that he has Java, JDBC and Oracle experience then he should >>> have at least some advantages going Java instead of .NET. >> >> Not to mention that those are all cross-platform options. while .NET >> locks you into a windows-based network. > > The way Mono is moving along that's not strictly speaking true. True. But Mono is only 98% MS .NET compatible or so, which either is not compatible or requires extra work to ensure compatibility. > In any > case, being "locked into" a Windows-based network is not exactly a > liability, not now and not for a few more decades. As it is, the > majority of fellow developers and clients that I deal with do J2SE/J2EE > on Windows. Every job I've had there's always been a fair bit - often a > majority - of other applications that have been on Windows. So it may be > a point of pride that your app in theory could run on many OS's, but > since almost everyone will have Windows who really cares? The database is running on non-Windows platform today and he indicated interest in Unix as database platform. Windows is big but it is not everything. Arne
From: Arne Vajhøj on 10 Jun 2010 18:13
On 10-06-2010 06:45, Arved Sandstrom wrote: > Arne Vajh�j wrote: >> On 09-06-2010 20:19, Arved Sandstrom wrote: >>> JC wrote: >>> [ SNIP ] >>> >>>> Off the top of my head, I am thinking of a Unix based version of >>>> Oracle for >>>> the DBMS. 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. All this with my limited knowledge of what's out there >>>> today. I >>>> might be a dinosaur but certainly not stupid; I am quite capable of >>>> learning. I haven't been to school since 1996 when I graduated with a >>>> BS in >>>> Comp/Sci & Math. >>>> >>>> Many Thanks to any/all that respond ... >>> >>> I realize that you posted to Java newsgroups, and others have already >>> provided good advice for Java-based work. However, in line with where >>> you say you're currently at, I would recommend investigating a .NET >>> approach in parallel with following up the Java/J2EE leads. For a web >>> application you might then be looking at ASP.NET MVC 2, using C# as your >>> primary programming language, with SQL Server as your database. The J2EE >>> parallel to this could be JSF/Facelets in Java EE 6, with Java 1.6, >>> using Oracle or PostgreSQL. There are lots of permutations, obviously, >>> but these are broad brush suggestions. >>> >>> Would I recommend one over the other, J2EE over .NET, or vice versa? No, >>> I simply recommend being aware of both technology sets. Especially since >>> you are essentially coming in at ground zero, which is not necessarily a >>> disadvantage here. >> >> Given that he has Java, JDBC and Oracle experience then he should >> have at least some advantages going Java instead of .NET. >> > Based on what he said I wouldn't consider that to be a significant > advantage however. An ancient version of Java, for starters. And by his > own admission he's no DBA, so even discounting the old version of Oracle > he doesn't have admin chops on the database side either. Even though Java 1.1 is old, then the code should still work on a newer Java (there are few potential issues, but generally). 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 |