×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Thoughts On the State of Web Development

kdawson posted about 4 years ago | from the sofea-meet-soui dept.

Java 253

rmoskal recommends his blog post up at Most Media on finding the right level of abstraction, Grails, and SOFEA. "[Three years ago] I was very excited about Apache Wicket as the way to develop line of business applications with a domain model, CRUD [create-read-update-delete] screens for maintaining the model, and in the most interesting cases, doing something else useful besides. I still like Wicket. It has, as its website says, a small conceptual surface area.' It reminds me of Python in that 'You try something it usually just works.' In many respects, though, Wicket seems to be at the wrong level of abstraction for the for the sorts of line-of-business applications described above. If your team is spending any time at all writing code to produce listing, filtering, and sorting behavior, not to mention creating CRUD screens and the back-end logic for these operations, they are probably working at the wrong level of abstraction. ... Recently I did a small project using Grails and was quite pleased. Grails uses groovy, a dynamic language compatible with Java, and is based on the proven technologies that I know and love well: Spring, Hibernate, SiteMesh, Maven, etc. ... I get all the power of the Java ecosystem without the fustiness and lack of expressivity of the core language (no more getters and setters, ever!)."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

253 comments

getters setter :) (4, Insightful)

roman_mir (125474) | about 4 years ago | (#31890510)

First, getters/setters are generated by your IDE of-course, so you never have to write them by hand, however, more to the point, I have avoided many various parts of the 'Java ecosystem', while still using that language to do all sorts of development and really, you don't have to use getters/setters. I use many Java classes as simple data structures, just like C-Gods intended, no getters or setters there, just public or protected fields.

Re:getters setter :) (-1, Offtopic)

Anonymous Coward | about 4 years ago | (#31890550)

I fucked your dead great grandmother.

Re:getters setter :) (1, Funny)

Anonymous Coward | about 4 years ago | (#31891034)

Jokes on you, necro-boy!
She was a vampire who died of leprosy and now you're gonna have to pay for your blood at the Wal-Mart pharmacy and drink it through a straw after your teeth fall out!
And guess which part of your anatomy is gonna fall off first!
Fuckin' dumbass necrophiliacs can't even read warning signs at gravesites.....

Re:getters setter :) (2, Informative)

Anonymous Coward | about 4 years ago | (#31890694)

Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;
2.7 times longer line than it ought to be. And with current java IDE-generated non-VM supported getters/setters all of the shorthand abbreviations such as ++ -- += -= *= etc are unusable. Good luck writing any complex formulas on one line with such getter/setter syntax :P

Re:getters setter :) (1)

binarylarry (1338699) | about 4 years ago | (#31891010)

all of the shorthand abbreviations such as ++ -- += -= *= etc are unusable

So you're saying we can't implement Brainfuck for Java? OH NOES

Re:getters setter :) (0)

Anonymous Coward | about 4 years ago | (#31891240)

Only a Java-tard would be opposed to something as simple and elegant as unary operators.

Re:getters setter :) (1)

roman_mir (125474) | about 4 years ago | (#31891310)

Geez, again with the same excuse: "My IDE generates them automatically". Yes it does, but Java IDE's are not the only one's that can do that, duh.

- 'duh' what? Where do you see me arguing against this point?

Deeper problem is that you later have to use those "fully automatically with just a few special clicks" getters and setters like this in your code: point.setX(point.getX()+1); instead of just writing point.X++;

- again, what? I said I use classes often without getters / setters, so this is exactly what I can do. Do you understand that getters / setters are a choice and are not mandatory? They are not required by the language. I think you do understand that, you just are not understanding what I wrote in my first comment.

Re:getters setter :) (0)

Anonymous Coward | about 4 years ago | (#31891558)

++, --, +=, -=, *= etc are all just calls made on a basic data type or class, in the case of strings. If you extend your classes or methods, you can indeed use ++ instead of your example. It becomes a little bit harder to see what's going on. If I knew I was going to have to increment an integer value, I'd probably just write a method called incrementX(int). I think point.incrementX(1) is just as clear as point.X++ and much clearer than the get/set, and more powerful. You don't write a get/set for every little variable, only the ones you need. That's the whole point

Re:getters setter :) (1)

ebuck (585470) | about 4 years ago | (#31892314)

If you're really sweating the point.setX(point.getX()+1) call pattern, pray tell why don't you create a point.increment() method? Of if you need more flexibility, a point.add(1) method? It seems like you're really trying to program like an idiot to prove you point that idiots program in Java.

Re:getters setter :) (1, Informative)

Anonymous Coward | about 4 years ago | (#31890742)

If you are using Java 1.6, look into project lombok:

http://projectlombok.org

You annotate your class with @Data and the getters and setters are generated as you add/remove private fields.

Re:getters setter :) (1)

hpoul (219387) | about 4 years ago | (#31890796)

i still don't get why people think auto-generated code is easier to maintain than hand-written one.. (i think there was some saying that code should be optimized for reading?)

if things can be auto-generated by an IDE, why not auto-generate it during run-time? (obviously only the first time to avoid performance impact). don't get me wrong.. i like java.. but compared to the web frameworks available in other languages (e.g. python with django) all java frameworks are just a pain (struts 2, wicket, JSF, ...) which are barely bearable with the right IDE.. (yes, if you are developing your next online banking application or million hits per second online store it might be necessary..) -- that beeing said, i still prefer the next best java project over some php kiddie-project.. at least i can find my way around getters and setters, there is no way i stay sane trying to figure out where some weird global variable come from... (speaking from experience.. which means i've probably already lost my sanity anyway, so feel free to ignore me ;) )

Re:getters setter :) (1)

CptPicard (680154) | about 4 years ago | (#31890852)

The idea with getters and setters is that in the end the value may not actually be a field (it may be computed), and interfaces can't contain fields. Plus the JavaBeans style naming conventions are pretty ubiquitous in the Java world... not sure if everything works right with just plain fields like that (it may).

Re:getters setter :) (1, Interesting)

Anonymous Coward | about 4 years ago | (#31891066)

The problem is that the implementation sucks. How about rather than making everyone call functions to get or set variables, making the access to the variable automatically call the appropriate getter or setter if it exists? You could even add a "controlled" member type (to public, private and protected) to indicate that the variable should only be accessed via getter/setter (read-only variables would then have no public setter, as opposed to being written to directly)

Re:getters setter :) (1)

roman_mir (125474) | about 4 years ago | (#31891292)

As long as this is my project, everything will work without getters/setters where I choose not to use them.

Re:getters setter :) (1)

yabos (719499) | about 4 years ago | (#31891836)

At my job they like you to use getters/setters for everything, even inside the class when accessing private members. To me this is pointless and a waste of time requiring a method call when you really don't need one. I can understand the reason for encapsulation where you want to protect certain things from outside access but to have to use this.getter() rather than this.variable inside the class really makes me want to puke. IF java wasn't garbage collected and the getter/setter actually did something rather than just setting a pointer then I could understand using the setter/getter inside the class.

Pros & Cons of both approaches + Ring 0 vs. Ri (0)

Anonymous Coward | about 4 years ago | (#31892222)

"At my job they like you to use getters/setters for everything, even inside the class when accessing private members. To me this is pointless and a waste of time requiring a method call when you really don't need one" - by yabos (719499) on Sunday April 18, @09:48PM (#31891836)

It's what creates the object-oriented encapsulation in effect though, & yes, you lead to this in your next quote: Sad part of it, will be what I am going to illustrate as fact that circumvents that "OOP" encapsulation, no matter how you implement it in usermode / Ring 3/ RPL 3 & it actually furthers your case, in a way:

"I can understand the reason for encapsulation where you want to protect certain things from outside access" - by yabos (719499) on Sunday April 18, @09:48PM (#31891836)

Here's that "sad part" - it wouldn't protect an OOP designed program, protected/private vars & datastructures + getters/setters used, running in std. usermode/RPL 3/Ring 3 program, from a Ring 0/RPL 0 executing device driver (like what you see rootkits using for example...) - think about that one!

Getting it to produce proper results is job #1 though, speed comes last, but solid code design (err traps & all, plus OOP when possible is #1... however, think about what I said above about drivers (they can reach into ANY RPL3/Ring3/Usermode process' memory spaces (yes, even the OS, but it can cause crashes too), anytime + ANYWHERE they want (thus, defeating OOP encapsulation in std. RPL3/Ring 3 apps... & what uses drivers? ROOTKITS DO... for reads? This would be a silent, safer, & non-crash prone way to GET DATA (think espionage))))

So much for OOP &/or/+ encapsulation, eh?

APK

P.S.=> Do I use OOP?? Yes - especially for production code. Sometimes you cannot help it because you call libs OR have to use prebuilt controls &/or structures that use OOP too! To be honest though, I'd rather have usermode code be OOP safer & slower stuff, err traps & all, than an "absolute speedster" (meaning optimized to the Nth level/max) MOST of the time...

However, not when something needs speeding up, & then I either head to a faster language + if possible, put more inlined or procedural code into it rather than classes &/or full blown objects (worst are externalized into libs such as .ocx or .dll in Win32 for instance, for speed @ least, but not reusability) & then good compiler switch optimizations @ most usually then, for gaining speed!

(Lastly, going to "dropping to" character mode/DOS Command Prompt/TTY console mode for even more speed, vs. GUI - 10x gains imo @ least, seen it in C/C++ &/or Delphi in doing so when possible (not all apps lend to it userfriendly wise either though))

That's in usermode end user app oriented GUI (mostly) coding, sometimes I have to do a console mode one for better speed IF the user doesn't mind it (some do bigtime), provided a compiler's IDE can generate a console app that is (not all do that are quick & non-interpreted code by a runtime but statically linked true .exe files that only depend on OS API functions, rather than a runtime)...

I guess what I am saying is, it really depends on the situation @ hand, & its demands for code I write for myself, or for employ/customers + tools they give you to use (yes, companies as I am sure other programmers here will know, DO standardize on tools used, because it saves them monies in licensing them mainly, & I don't blame them that)... apk

java centric (2, Informative)

thetoadwarrior (1268702) | about 4 years ago | (#31890554)

This isn't really about web development in general but Java web development and writing getters / setters is the IDE's job.

Using Java for web development (5, Insightful)

Banacek (994201) | about 4 years ago | (#31890598)

Using Java for web development is like using a wrecking ball to hammer in a nail. Use something that fits the job better, like Zend Framework, Django or Ruby on Rails. In web development, time to market is everything. Build your application and hopefully you get a large user base. Then when performance is an issue, you should already be working on a rewrite that can incorporate something like Java on the backend.

Re:Using Java for web development (2, Interesting)

Anonymous Coward | about 4 years ago | (#31890696)

Or just dump the server side all together, seriously with the maturity of the JavaScript frameworks, there is no reason to build on restrictive server side technologies, just build your UI with HTML/CSS/Javascript and communicate back to RESTful services implemented in whatever language the back end team chooses. This fixes a lot of things that where broken in web development not to mention that it is a far faster development style and is more maintainable to boot.

Re:Using Java for web development (2, Informative)

Daengbo (523424) | about 4 years ago | (#31891668)

TFA (Shock! I read it) says that this is his new preferred method. Separate all the server and client-side logic. Push almost all the logic into the client.

Re:Using Java for web development (1)

Lennie (16154) | about 4 years ago | (#31890706)

I think the only reason this even made the frontpage is because the editors like a good discussion.

The subject pretty much doesn't interrest anyone, right ?

People who do not learn from history.... (4, Insightful)

Kenneth Stephen (1950) | about 4 years ago | (#31890926)

...are doomed to reinvent J2EE. Badly I confess that I haven't tried any of the frameworks mentioned by the parent. But I have had conversations with people who have, and here are some questions that I have for the folks who think that the people who came before them (and invented J2EE) are stupid:
  1. Can your framework handle two-phase transactional commits when it interfaces to other applications?
  2. How well does it support single-sign across apps deployed across different servers but behind a reverse proxy that unifies them under a single domain?
  3. Can you cluster multiple hosting servers for your app to minimize downtime during app upgrades? Does your application sessions failover to the other members of your cluster correctly, if so?
  4. Can you take legacy code and layer your app around it without needing to rewrite the legacy app? Can you do this even if the programming team who wrote the legacy app is no longer around?
  5. When you discover that you are having intermittent glitches (slow responses / server 500 response codes /etc), do you (a) reinstall (b) upgrade to a newer version of your framework / OS / whatever (c) Troll the user forums for your product / framework and hope that someone has seen your problem before. (d) Pull three all-nighters reading the source code to your product / framework? [Hint. The right answer is (e) Put your product into a supported trace mode and get your vendor to support you]

IMHO, programming language wars are silly. The proof of the pudding is in what you can achieve with the framework of choice. After many years of observing the competitors to J2EE, I have yet to see a professional grade alternative to it.

Re:People who do not learn from history.... (2, Interesting)

inKubus (199753) | about 4 years ago | (#31892324)

These kids today who act like there's some art to programming that's instinctual, that they should be comfortable programming when they don't know shit about the language they're using. Guess what, C is the most comfortable language ever invented. Perl is one of the fastest to write.

Of course, perl is designed for text. HTML, while a subset of "text", is a pretty complex markup language. To generate such code using another language is not trivial. Then you're dealing with networking, web servers, the internet, unknowns like browser type and user screen resolution. Then you have various databases on the back end. It's a very complicated problem yet kids think somehow the computer (or someone else) should just solve it.

The problem is that frameworks are generic and your app is specific. Yeah, the basic types are always there, CRUD, forms, lists and datagrids. But the amount of variance between two "lists" can be huge. A styled list that may work great for a list of books might be horrible for a list of people.

There's no way a framework is going to define base types for every possible thing you could have in a list. The frameworks and object-relational mapping engines are just tools to assist you. You still have to classify everything and their interactions. You still have to define a logical flow for every feature. You still have to test everything. That's what a programmer's job is! So, kids, you're never going to have something that will abstract away the programming. As much as you'd just like to point at the computer and magically create an "app" like you paint a picture, it's not possible, has never been and never will be. "Fustiness and lack of expressivity"--shut the fuck up and get off my lawn.

Re:Using Java for web development (0)

Anonymous Coward | about 4 years ago | (#31891198)

Agility, shortest time to market, tested code and simplicity are the principles of grails, copied from Ruby on Rails.

I have a lot of django and grails experience and I consider all these frameworks equivalent.

My biggest criticism of grails is in it core. Spring + HIbernate + Sitemesh + Tons of java classes are way to complex and generate huge stacktraces. There are some benefits to using this approach however.

In the outside, grails and groovy makes your business code very simple and concise however.

 

But Grails is like Rails (1)

shis-ka-bob (595298) | about 4 years ago | (#31891750)

Really, try it. You can leverage many existing Java-centric frameworks. Sitemesh, Spring and Hibernate are fast & stable. Grails takes the 'suck' out of using them. Rewrites are easier, since you are already 1/2 way to Java. Find the bottle neck, rewrite it in Java and away you go.

Re:Using Java for web development (1)

Tumbleweed (3706) | about 4 years ago | (#31892038)

Using Java for web development is like using a wrecking ball to hammer in a nail.

Actually, *that* sounds pretty effing cool, almost Mythbuster-like! I'd like to try that some time. But using Java for web development? *That's* just crazy-talk.

Need a New UI Tool (5, Insightful)

Tablizer (95088) | about 4 years ago | (#31890610)

As I've said before on slashdot, the open-source movement should look at creating a new GUI browser that does desktop-like and CRUD GUI's well. Forcing the e-brochure-like HTML-based browsers to act like desktop/CRUD GUI's is like trying to roll Pluto up Mt. Everest: people have kept trying to pull it off with AJAX and whatnot for more than a decade, but it's still kludgy, bloated, buggy, security-challenged, and version-sensitive.

It's time to throw in the towel and start a new tool and markup language.
   

Re:Need a New UI Tool (1, Informative)

Animats (122034) | about 4 years ago | (#31890634)

Forcing the e-brochure-like HTML-based browsers to act like desktop/CRUD GUI's is like trying to roll Pluto up Mt. Everest: people have kept trying to pull it off with AJAX and whatnot for more than a decade, but it's still kludgy, bloated, buggy, security-challenged, and version-sensitive. It's time to throw in the towel and start a new tool and markup language.

Right. Java applets!

Re:Need a New UI Tool (1)

Tablizer (95088) | about 4 years ago | (#31890868)

The biggest problem with Java applets is that they pretty much force you to use Java as your programming language. Many of us want language choice.

The second is that it often required downloading a mini-OS-like blob to the client for each session.

A lot of this can be eliminated by create a good "GUI Markup Language" native to the browser such that the common 95% of typical GUI/CRUD behavior can be handled by the markup language, reducing the need for client- and server-side imperative code. (XUL tried this, but they didn't seem to understand the CRUD world.)

I've kicked around ideas for such a markup language, and one idea that seems useful is to allow the developer and/or user to switch between an MDI, tabbed, and "stacked" view of multiple windows/forms via a simple option switch. Most existing interfaces hard-wire you with one choice, or make it difficult to switch. If one can do this in a nested manner within "frames", then it's easy to create things like "ribbon" menus etc. using existing GUI idioms instead of reinventing the wheel. The combo of the tri-type-window switch and frames can build almost anything you see in typical GUI's (assuming you have the common widgets such as editable data grids, tree/outline widgets, combo boxes, etc.)

Re:Need a New UI Tool (3, Insightful)

icebraining (1313345) | about 4 years ago | (#31890924)

The biggest problem with Java applets is that they pretty much force you to use Java as your programming language. Many of us want language choice.

Well, there's at least proofs of concepts for Ruby (JRuby), Python (Jython) and Groovy.

Re:Need a New UI Tool (1)

binarylarry (1338699) | about 4 years ago | (#31891062)

Those aren't really proofs of concept, they're used in many production environments.

The JVM is basically king of multilanguage "common runtimes." There are tons of languages targeting it.

Re:Need a New UI Tool (1)

icebraining (1313345) | about 4 years ago | (#31891394)

Those aren't really proofs of concept, they're used in many production environments.

Proofs of concept using those languages in applets, not in any kind of app.

Or are they used for applets already? I couldn't find much info about it.

Re:Need a New UI Tool (1)

unother (712929) | about 4 years ago | (#31892264)

Not to take away from your answer, but OP was j/k. He was saying "it's 1996". :)

As for XUL... well, there's another semantically-bloated language.

Oh, and in XUL's case: "it's 1999". :D

Re:Need a New UI Tool (1)

mikael_j (106439) | about 4 years ago | (#31890644)

The main issue with (X)HTML is that it's not meant to be used for application user interfaces. This shows partly in the types of "widgets" (form elements basically) available and in the severely lacking layout possibilities.

Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

Re:Need a New UI Tool (1)

AlXtreme (223728) | about 4 years ago | (#31890808)

Building basic user interfaces for various business web apps is probably the most frustrating part of web development, and the frustration coming dealing with building user interfaces using HTML, CSS and Javascript is definitely a major contributing factor.

This was my view on web development for quite a while, until I gave jQuery a try and put aside some time to properly understand CSS. It's honestly not that bad.

There still is a bit of frustration (in getting everything perfect on all major browsers) but the advantages of having a cross-platform interface easily accessible via a browser outweigh the drawbacks. Besides, with HTML5 picking up steam the future of web development looks bright.

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31891192)

The most broadly useful part of the HTML5 spec is finally extending the ancient HTML form tags to include data types like 'date' and 'integer', as well as client side validations.

Except, all the browser manufacturers (except Opera) have overlooked HTML5 forms in their rush to implement video and other "flash killer" features.

Re:Need a New UI Tool (1, Informative)

Anonymous Coward | about 4 years ago | (#31890728)

haven't they been trying this with flash, silverlight, javafx?

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31890874)

No, those are for crappy animation. XUL does exactly what GP wants though.

Re:Need a New UI Tool (1)

Tablizer (95088) | about 4 years ago | (#31890908)

and most are proprietary. I tried to like XUL, but it seemed how it interacts with server-side and client-side programming/scripting, and it's update approach, were poorly thought out.

Here you can read about draft concepts that I personally think would work well:

http://www.c2.com/cgi/wiki?GuiMarkupProposal [c2.com]

Re:Need a New UI Tool (1)

antifoidulus (807088) | about 4 years ago | (#31890782)

Welcome to the world of legacy software.

Essentially HTML is the world's biggest legacy system. The problem with finding a replacement is that everyone in the world uses HTML, thats a consequence of what state the technology was in when the internet took off. Even if you could find a replacement, convincing everyone to switch over is a pretty gargantuan task, esp. when you factor in the chicken and the egg issue, you aren't going to get people to switch to your platform of choice unless there is content, but content producers aren't eager to port everything over to a system with very few consumers.

I guess it's human nature but .. (1)

ClosedSource (238333) | about 4 years ago | (#31891342)

It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time.

Or perhaps there could be two protocols available - one to support legacy sites and a new one specifically designed to facilitate web applications.

It would be great if you could have the most common AJAX-style transactions be available declaratively so that you could use them with little or no client-side scripting

Re:I guess it's human nature but .. (1)

turbidostato (878842) | about 4 years ago | (#31891614)

"It didn't take that many years to go from 0 users of HTML to where we are today despite the fact that most people didn't understand the potential at the time."

But HTML came first. Niche oportunity is already lost.

Re:Need a New UI Tool (1)

Tablizer (95088) | about 4 years ago | (#31891700)

Essentially HTML is the world's biggest legacy system. The problem with finding a replacement is that everyone in the world uses HTML

First, many would be happy to leave the HTML world if they could develop rich GUI's much easier. Yes, it does require a certain amount of momentum to make a product or tool become widespread and mature enough for use, but the hunger is there. After all, many develop in Flash, ActionScript, and Flex to get richer GUI's in a proprietary way.

Second, this proposed "GUI Markup Language" can borrow many idioms from HTML so as to not be too foreign.

esp. when you factor in the chicken and the egg issue, you aren't going to get people to switch to your platform of choice unless there is content

I expect intranets is where most the initial momentum would be. There, you have a bit more control of browsers. Complex GUI's are more necessary for internal and biz-to-biz work-related projects than internet services, in my observation because the total usage time per user of internet apps is relatively short.

If you make external apps too complicated, you lose customers, but internal apps can be more complex because they are related to specific jobs that need to be done in which some training and a learning curve is expected.

For example, HTML is generally fine for on-line bill paying. Rich-GUI's wouldn't add much to that experience. But if you have lots of screens, lots of forms, lots of inter-related data grids, and lots of data-entry, such as an internal customer management system, then desktop-like GUI features become quite helpful.

HTML-based techniques are okay for a "Wizard view" where the user is kept in a fairly narrow corridor and sees only a few things at a time. This reduces the necessary training. However, for complex work tasks, you often need several items readily available at the same time and it should be easy to see and access them simultaneously, or at least switch context rabidly.
     

Re:Need a New UI Tool (1)

Nikker (749551) | about 4 years ago | (#31892334)

The only problem with HTML is in the interpretation. With every other language being high or low level if it runs it runs the way the programmer intended. With HTML, one line of HTML can behave differently for each browser that interprets / renders it. Any method of communication falls on 2 people to be useful right now we are not getting that. If you had to write different classes for each of the possible targets you end up with a messy bloated heap. Now with web developers in many cases throwing CSS/JS/HTML at the client computer with coding and kludges for IE, FF and others it's insane enough for a person to read it and it sure doesn't make it any easier for the machine to parse it.

If HTML/CSS/JS was parsed and rendered exactly the same way across the board then you could make some elegant contributions and the language set would evolve. Scrapping HTML/CSS/JS is now just an unfortunate act of desperation because of the stupid (not enough of an understatement) browser "wars". Ultimately we need the ultimate sandbox, from there we can write anything we want and the client will be able to make their easy going clicks that the web mentality thrives on. HTML/XML will always be needed in one form or another because it is, 1) good for keeping the description of the appearance concise and 2) the data transmitted can easily be compressed and bad data due to transmission can easily be detected. As always if you had to code any web site in pure Java, C or any other binary compiled language just think about how much you would have to do just to get your banner up. You would have to deal with graphics drivers / OS interfaces, render fonts, deal with screen dimensions dynamically just to show a GIF, all that work for a fraction of a project is a waste. Once we get either cross the board browser/client support we can start moving forward until then complaining about HTML is going to take us no where.

Re:Need a New UI Tool (1)

thoughtsatthemoment (1687848) | about 4 years ago | (#31890788)

The cost of developing a new browser is high. Just take a look at the code bases of firefox, or webkit/chromium. They are huge. Where are the developers for starting a new one? If you are asking Mozilla to abandon firefox/gecko, it's not gonna happen anytime soon.

Re:Need a New UI Tool (1)

Tablizer (95088) | about 4 years ago | (#31891522)

The cost of developing a new browser is high. Just take a look at the code bases of firefox, or webkit/chromium. They are huge.

A lot of it is due to backward compatibility. A new GUI standard won't have that problem. And the cost to the industry of doing GUI's wrong is also high.

Further, there are already open-source GUI engines out there, such as the TK family. They just need some taming for WWW use.
         

Re:Need a New UI Tool (1)

master_p (608214) | about 4 years ago | (#31890840)

Interesting, but why not take it one step further and do a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available. The mechanism will make sure components are cached locally in an appropriate manner.

I dream of the day that I can import components from URLs... (import www.mycompany.com/mycomponent, for example).

Re:Need a New UI Tool (1)

icebraining (1313345) | about 4 years ago | (#31890950)

You mean like Javascript?

Any interpreted language can easily do it. Just download the file with the code, check it against some hash/public signature and import it.

You could do a proof of concept in Python in 30 minutes, using nothing but the standard library.

Re:Need a New UI Tool (1)

thoughtsatthemoment (1687848) | about 4 years ago | (#31890956)

Security risk if you allow downloading binary. Otherwise it wouldn't be much different from Javascript architecturally.

Re:Need a New UI Tool (1)

Jaime2 (824950) | about 4 years ago | (#31891082)

The VM provides security, not visibility to the code. 99.99% of all people don't read the Javascript in their web applications, they let their browser deal with security issues.

Microsoft has a good strategy with .Net. Any code (yes binary) that is loaded from a URL not in the user's trusted sites list runs with pretty much zero permissions. It can display windows and communicate back to the site it came from, but nothing else.

Re:Need a New UI Tool (1)

shutdown -p now (807394) | about 4 years ago | (#31891054)

You have just described Sun's Java Web Start, and Microsoft's ClickOnce.

Re:Need a New UI Tool (1)

Jaime2 (824950) | about 4 years ago | (#31891250)

Both of those are whole applications, not components. It's more like anything that implements SOAP, or Microsoft's WCF.

Re:Need a New UI Tool (1)

shutdown -p now (807394) | about 4 years ago | (#31892364)

No, actually, they work just as GP described:

a lazily-downloaded environment, so as that applications can be super rich like desktop apps and still have all the advantages of web apps? app components could be downloaded strictly on a need basis and only when new versions are available.

They do indeed download classes (or, in case of ClickOnce, .NET assemblies) from the web as they are needed, and also do version-checking every time this happens, so if class/assembly updates on the server, it will be automatically refreshed on the client next time it is used.

Now, I don't think either one lets you reference components from varying base URLs - at least ClickOnce requires a single base URL for all components, if I remember correctly.

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31892288)

see: Flash/Flex

Exactly what you describe. Compile an app in to multiple dependent SWFs, load them on demand. Near desktop quality richness.

Re:Need a New UI Tool (2, Informative)

phantomfive (622387) | about 4 years ago | (#31891092)

It's not even just that: as soon as you get out of the three column format, HTML has trouble. The idea of CSS is sound, to separate the presentation from the content, but in practice it fails (if you don't believe me, ask yourself this: when was the last time you used a

div

as a line break? That's really not what they're for).

It's sad, but the problem is HTML has been developed by a committee, and not just a committee but a committee with conflicting goals. Some people want to make desktop-like GUIs, others want to make it impossible to define precisely what your page will look like in a given browser (this makes it more portable, in theory). Some people on the committee are thinking in terms of page layout, and some are trying to manipulate it in any way possible to give their browser a competitive advantage.

With all this in mind, HTML makes a lot more sense.

Re:Need a New UI Tool (2, Informative)

Hurricane78 (562437) | about 4 years ago | (#31891296)

It’s called QtDesigner & friends. Or XUL. Look it up.
Basically, it’s an old hat. A very old hat. I did things like that back in 2003.

I’m back to plain and simple... compiled desktop/server/mobile programs. I still use something like XUL (but in EBML with a tag-mapping attachment), but I mostly generate that “XUL” from SQL DDL, as an itermediate representation, and plain machine code as a final result.
As an example: A complex application usually takes the time to write a clean SQL with the appropriate interfaces (30-60 min), a run of my generator (3 seconds?), then I add a bit of non-standard business-logic (duration depends. Between 20 minutes and a whole week.), use a small tool to generate a color palette and fonts for the design (15 min), edit a tiny text file of annotations, and run the final compilation (<5 min).

Done.
That thing now has a an optional server part, a AJAX browser client, a real full application for Windows, Linux and Mac, and a small but full-featured (no compromises!) phone and PDA client. Done, done, and done.

So with a big of luck, I can churn out a $2000 tool in a day, and a $10000 tool in a week.
But I do not really like doing stupid apps for stupid business clients. So I do as little as possible.
Which explains why I can hang out here all day long, posting lengthy comments. :)

(My main business is game design, but since the money is not coming in as much as planned, I haven’t stopped doing stuff like this yet. Maybe I should hire someone to do it for me, and just become Leisure Suit Larry. ;)

Re:Need a New UI Tool (1)

Tablizer (95088) | about 4 years ago | (#31891784)

But I do not really like doing stupid apps for stupid business clients. So I do as little as possible.....My main business is game design, but since the money is not coming in...

I generally do like doing biz apps, but I don't like spending long hours trying to get the UI to work right. I've been spoiled by desktop tools that let one build and maintain complex GUI's in about 1/5 the time as a similar web app, which break on browser version n + 1 anyhow.

As far as XUL, I've been disappointed with XUL, per other messages. Maybe they've fixed the ugly or undefined spots since I've last explored it? It seems it's mostly used for FireFox pluggins, not biz apps.

Also note that maintenance is often a bigger part of software effort than original creation of software. It seems you do a lot of "hit and run" contract work where you don't have to fix your creations, or actually want to have to fix them for the money, and so don't care about making them maintenance-friendly. If one is an internal app developer, then maintenance effort needs to be given more attention.
   

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31891314)

You mean like Silverlight and XAML. Or Actionscript and Flex.

We've had it for years. It's called Qt. (0)

Anonymous Coward | about 4 years ago | (#31891336)

We've had this platform for years. It's called Qt [nokia.com]. It's free, it's open source, and it runs just about everywhere, on just about any OS.

It even includes numerous classes [nokia.com] to make network-aware application development damn easy. It's much easier than performing AJAX requests and handling their responses, for sure.

Best of all, it is written in C++, a proven, well-supported language that performs very well in most circumstances, and is suitable for large-scale development. It's a lot better than that hack they call JavaScript, which starts becoming unmaintainable once you go beyond writing an onclick handler.

Re:We've had it for years. It's called Qt. (1)

Tablizer (95088) | about 4 years ago | (#31891870)

It seems heavily tied to C++ as your app development language. Scripting fans won't like that. Also, how it would work over HTTP is not clear. And, a GUI-Markup-Language would be the more popular and practical route, with imperative programming only around the edges for the custom stuff not handled by the markup language. If somebody put a markup wrapper around QT and worked out how it functions over HTTP, then you may have something.

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31891964)

Wasn't that what XFORMS was all about?

Re:Need a New UI Tool (0)

Anonymous Coward | about 4 years ago | (#31892014)

This is what I designed Brainstorm for. Java based with no coding necessary on the client, reusable client deployment, and built on SWT so the L&F is native (can also deploy via other UI systems as well). All UI code is written with very simple xml (very simple) and turned into class files at compile time for the targeted UI system, which are deployed to the client like html is deployed to a web browser. Even better I got rid of the need to write any glue code between the view and the model/control code. (brainstormframework.com)

Re:Need a New UI Tool (1)

double07 (889350) | about 4 years ago | (#31892190)

It's time to throw in the towel and start a new tool and markup language.

Hmmm... I know, how about Flash!

Re:Need a New UI Tool (1)

mandelbr0t (1015855) | about 4 years ago | (#31892326)

It's time to throw in the towel and start a new tool and markup language.

Or maybe spend long enough on a single version to make something stable. The "new" tool and markup language has been done plenty before. SGML wasn't good enough, so then came HTML, then HTML wasn't good enough, so there was XML. Apparently now XML isn't good enough, so we need SuperMegaMarkUpLanguage. It's funny, but software projects actually require time to mature. There needs to be a phase of "hmm this almost works, except..." instead of "these really minor annoyances are no good, gotta start over."

Of course, when "almost works" ecomes "barely works", or "minor annoyance" becomes "we need someone on-call to deal with this", I can see the need for a rewrite. Maybe I'm not much with XML, but it seems to be in the "almost works" category. Certainly, I would rather see XML reworked than wait for SMMLUL, and Microsoft's fucked-up interpretation of it.

Author should look into Scala (1, Interesting)

Anonymous Coward | about 4 years ago | (#31890616)

Scala gives you most of the same benefits of groovy with the addition to being statically typed. The lift web framework is very nice (albeit poorly documented), especially with its ability to generate pain-free AJAX/Comet for you.

ps I would hardly call this article "the state of web developement." Maybe "the state of Java ecosystem web development", but even that seems a bit of a stretch.

Re:Author should look into Scala (1)

SQLz (564901) | about 4 years ago | (#31892114)

Too bad scala is awful. Great for academic use, aka annoying students. Why anyone would want to take 10x longer to code in the real world means a. they are dumb, b. they have money to burn and don't care.

getters and setters (0)

Anonymous Coward | about 4 years ago | (#31890670)

I never understood the love with getters and setters, it would be so nice to only have to create getters and setters if you want to override default get and set behavior, like for setting lists I like to check if its not null first, but why do I have to create getters and setters for all my variables all the time, seems like a waste to me.

Re:getters and setters (2, Insightful)

AuMatar (183847) | about 4 years ago | (#31891080)

In Java, its a weakness about interfaces- you can't have a data member in an interface, so any interface needs to use getters/setters.

In most languages, its so you don't give direct access to internal variables. In C++, you can just make the data member public and assign to it like a normal variable. But then you can't protect what is stored there or do sanity checks. Or you can write a getter/setter to do so. And if you decide to change from one to the other, you need to go back and change every access everywhere- a pain. Some languages like C# provide syntactic sugar to allow you to use foo.bar=9 and have that call a function, but there's problems with this- its impossible to know when you're calling a function or not by inspection, so you can have bugs that are difficult to find by code inspection- = does not always do what you expect it to. I prefer writing getters and setters to that.

Re:getters and setters (0)

Anonymous Coward | about 4 years ago | (#31891764)

... Some languages like C# provide syntactic sugar to allow you to use foo.bar=9 and have that call a function, but there's problems with this- its impossible to know when you're calling a function or not by inspection, so you can have bugs that are difficult to find by code inspection- = does not always do what you expect it to. I prefer writing getters and setters to that.

I've been reading, writing and debugging C# for many years now and properties are usually only a problem when they try to do too much in their getter or setter. Since the author writes the get/set code, I'm not sure how writing public function string getName() { } is better than public string Name { get { ... } }. In fact, I think the .Net way is a whole lot nicer.

Traditionalist here (1, Insightful)

hessian (467078) | about 4 years ago | (#31890758)

Only Perl is true!

Re:Traditionalist here (0)

Lord Ender (156273) | about 4 years ago | (#31891684)

Whether you like Perl or not, you must admit that it is becoming a "legacy" language. Learning Perl today is gunning for a job as a maintenance programmer.

These days, "enterprise" software uses Java or C#; high-performance or hardware-intimate software (games, science, OS, microcontroller) uses C or C++; and general-purpose or web-development software uses Ruby, Python, or PHP. Perl has been squeezed out of its niche.

Re:Traditionalist here (1)

mandelbr0t (1015855) | about 4 years ago | (#31892348)

Learning Perl today is gunning for a job as a maintenance programmer.

Or a Unix SysAdmin. Assuming the breed doesn't die out :-S

Title of summary is wrong (1, Insightful)

paziek (1329929) | about 4 years ago | (#31890768)

Title of summary is wrong, its not about web development.
What is the purpose of this? Don't we want to go away from Java in web? It was slow back in the days, now its just yet another security risk that can compromise ALL browsers at once if Oracle/Sun screws up. And now some spin-off or whatever? No thanks.
What we really need is some kind of consistency between output of HTML/JS engines, as well as CSS, so that GUI "just works". There is nothing wrong with those languages/markups, just with the implementation. While I'm all for competition and browsers trying to be better at something from others, it seems to me that in this area they just should cooperate more. It was IE6 back in the days, now its all over the place with vendor-specific extensions, that instead of going first thru W3C, they just are added to the browser with -moz/-webkit/-whatever thats supposed to make it okay to do this? Or perhaps they want to take approach "Hey, we implemented X and its popular, can we force this into W3C now?", with I hope won't work very well for them.

Re:Title of summary is wrong (1)

micheas (231635) | about 4 years ago | (#31891036)

Um,

This is not about java on the client it is about java on the server via tomcat, jetty, or some other java app server.

All of the sites listed at http://www.opencms.org/en/support/references/index.html [opencms.org] are java based, as is opencms.org itself.

This is about getting the post blog entry function to work. the html is more or less trivial. The server side is a bigger issue, as you have access control. data sanitation, and bunch of other minor details that will get your website compromised if you screw them up.

This is about grails vs rails vs django vs drupal vs zope vs web app framework du jour.

Personally, I wish there was a way of including php code in python, so I could extend existing php with django, and slowly convert the legacy code.

Re:Title of summary is wrong (1)

shutdown -p now (807394) | about 4 years ago | (#31891086)

Java is not a security risk for browsers in the context of server-side web development (which is what TFA is about).

Rails is Awesome (0)

Anonymous Coward | about 4 years ago | (#31890842)

I began my Web Development career with PHP/ASP. Then, I moved to ASP.NET - sometime in between then, I learned CSS, Flash, and XML.

I continued building enterprise-level, data driven Websites with ASP.NET, until I couldn't stand supporting the closed-source ecosystem that is .NET anymore.

So, I moved onto Java-based frameworks, meaning; JSP, JSF, Apache Click, Apache Wicket, Tapestry, SEAM, GWT. Each one fell short it its own way - never coming close to the power, flexibility, and speed of development as ASP.NET.

Then, I found Rails. I am absolutely amazed at what I can accomplish with Rails, and the ecosystem it offers. I don't have to deal with hundreds of jars or dlls like in Java/.NET - I just install a gem with Ruby's handy little RubyGems. AJAX is baked right in, with tight integration around every corner. ORM is also built in, and migrations are just plain magical. If you're like me, and you still want the power and enterprise-loving ecosystem of Java, just run your app on JRuby. If that's not enough, the community is always willing to help - no matter how stupid your question.

Take it from someone who's given everybody a shot - Rails Rocks

Re:Rails is Awesome (3, Insightful)

binarylarry (1338699) | about 4 years ago | (#31891072)

It rocks until you need to support more than a dozen users. Then you need something like Java, which as proven to scale to meet any demand.

Just ask the folks at Twitter.

Re:Rails is Awesome (1)

symbolic (11752) | about 4 years ago | (#31891994)

It was documented at http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster [highscalability.com] that a language change would have provided a 10%-20% speed increase, while architectural changes that Ruby on Rails could easily accommodate would provide with them with increases of 10,000%.

Re:Rails is Awesome (1)

TheSunborn (68004) | about 4 years ago | (#31892278)

Except that it was not documentet at all. It was just stated as a fact with absolute nothing to back it up. Aka an analysis pulled out of his a**

Dammit Jim (-1, Troll)

Anonymous Coward | about 4 years ago | (#31890876)

Dammit Jim, I'm a doctor not a PHP fuckwad!

Is it just me (0)

Anonymous Coward | about 4 years ago | (#31891026)

Or is web development just too difficult?

Seems that you should be able to just describe what you want at a high conceptual level and all the code bits just be generated, allowing you to replicate your business rules at all the right places.

Alphabet Soup... (0)

Anonymous Coward | about 4 years ago | (#31891098)

Is it going to always be the case that "web developers" need to know more about the act of interacting with the "web programming infrastructure" than they do about the problem domain?

Thoughts from another experienced developer... (0, Flamebait)

Hurricane78 (562437) | about 4 years ago | (#31891170)

If your team is spending any time at all writing code to produce listing, filtering, and sorting behavior, not to mention creating CRUD screens and the back end logic for these operations, they are probably working at the wrong level of abstraction.

Agreed, BUT: I expect more from me, than the average developer. I expect to be at the very top. One of the best in the world. (Yes, that doesn’t mean I am always. ^^)
So none of the present libraries are even remotely acceptable to me. The one does one thing good, and the other one does the other thing good. But basically they are more of a “framework” mess, than a set of simple, separated libraries.
Which is why I did actually spend a lot of time on the above things. To custom-build my own system.
I think generating SQL from a UI design, is the wrong way around. So my system generates a UI from the database definition code. A bit like rails, but with a graph as the basic model of site structure, instead of a flat set with hacks.
Also, I made a separate library of every aspect of my abstraction toolbox.

Recently I did a small project using Grails and was quite pleased. Grails uses groovy a dynamic language compatible with Java and is based on the proven technologies that I know and love well: Spring, Hibernate, SiteMesh, Maven, etc.

Sorry, but I hate things like Grails or TypoScript with passion. The reason for this is, that their design is based on the inner platform anti-pattern [wikipedia.org]. In a nutshell, the recreate the environment they’re implemented in... badly. PHP and Java (in JSP form) already are dynamic scripting languages made for this task. Just use these, save a layer, lose nothing, and gain a massive performance boost for free. And: No. Grails and TypoScript are not easier to use. They are usually only easy, when you don’t want to do anything special. But usually, in my experience, there is no such thing as a project without something special. And on top, you have to learn new things in addition to the language you’re already using. It is silly.

I get all the power of the Java ecosystem without the fustiness and lack of expressivity of the core language (no more getters and setters, ever!

No you don’t get all the power. You get another pointless layer of abstraction. And if you want expressivity, then why start out with Java in the first place.
My rule of thumb is: If you are using a compiler, it must result in machine code. If you are using an interpreter, it must be in machine code. Prefer compilers over interpreters, and always only use one single compiler xor interpreter between your code and the machine. If you have more than that, you’re doing it wrong.

Which is, why my above system is not written in a scripting language, but mostly in Haskell and Python, with some Python scripts for quick code generation from the SQL model plus some annotations. The result is always compiled code. The result is always compilable to a normal GUI, web service or mobile device application.

But I’m in the process of phasing the whole thing out. It lacks in themeability (an issue, if your whole UI is generated automatically), and I want to write an even more generalized system. And this time I want to open-source it.
But you may not like it, as it will most likely not be usable from withing a browser. There are just too many efficiency and security issues with that. Also I nearly stopped doing webdev anyway. Too weak. I need a bigger challenge! :)

Frameworks do not work. Quit it. (1)

unity100 (970058) | about 4 years ago | (#31891174)

Sooner or later ANY client small or large, will come up with a 'change' that will require going way down the level to the underlying language, because of the intricate and out of the ordinary way they will ask it.

moreover, rarely will the two changes requested in similar area by two different clients will be the same. every business has their own style of running things, and what they will ask of you will differ from each other. this is even valid for small ecommerce presences on the web. you cant imagine the number and variety of different stuff they may ask.

there has been a lot of framework talk and numerous frameworks put out up til this date, yet the biggest and strongest ecommerce software and community remains oscommerce, despite its aging code (no templating, html mingled with php and so on). clients who start with even different software (leave aside frameworks) eventually move on to oscommerce due to unequaled community support. (innumerable modules, modifications available for free, all the service providers - any payment, shipping provider - know and support it and have modules for it, very cheap development fees and so on).

the disparage in between the success of software like oscommerce and any such hyped framework that has been put out so far shows that, as developers and programmers, we shouldnt close in on ourselves and go about being above all, and programming for ourselves instead of end users. it just ends up in elitism, detached from the reality.

Re:Frameworks do not work. Quit it. (1)

thoughtsatthemoment (1687848) | about 4 years ago | (#31891420)

You are talking like a scientist as if frameworks have to work for eternity. Frameworks are layers over the language or other libraries. How many layers are needed is something dynamic but that doesn't mean the layered approach is wrong.

Picasso.codeplex.com (0)

Anonymous Coward | about 4 years ago | (#31891910)

My approach has been to autogenerate the basic CRUD pages (and business layer), then customise those pages as required. Background infrastructure such as master-pages and css provides the necessary customisation. For the complete, free, open-source toolkit (for .Net and any DBMS), see: picasso.codeplex.com.

Apache Wicket (1)

dokebi (624663) | about 4 years ago | (#31892262)

I've been using this lately, and it beats the crap out of anything else I've seen. It _feels_ like I'm writing a swing app, but it's ajax enabled without writing javascript.
And since it keeps _all_ the logic (even loops to generate tables or bullets) inside java code, refactoring is trivial. I will never go back to a framework with a separate templating language again (I'm sorry, Django!).
!

Re:Apache Wicket (0)

Anonymous Coward | about 4 years ago | (#31892676)

struts2 apps dont have that problem, and dont have the complicated form stuff that wicket has.

i want to like wicket, and i tihnk it has potential. but struts2 (AKA webwork) is a lot simpler in many ways.

Play framework is the way... (2, Interesting)

jbwiv (266761) | about 4 years ago | (#31892582)

Rails? Been there. Grails? Done that. Both are decent. Rails is very good, but the abuse of open classes gets old quickly. Grails is ok, but it's really just a thin veneer over a complex mix of Java projects, and God help you if you run into any problems, because you'll be dealing with a stack trace that's 1000s of lines long, and you be troubleshooting these underlying complex java libs. For me, the play framework (http://www.playframework.org) is the best Rails-like approach on a Java platform. It stays very close to rails, so if you know rails learning it is easy. It's very pragmatic and very fast. It doesn't require a compile step to see your changes. It just works. Best of all, the code is clean and easy to troubleshoot. I suggest you check it out.

AJAX "more stories" functionality (0)

Anonymous Coward | about 4 years ago | (#31892594)

One thing comes to mind when I think of the state of web development today. Web 2.0, and all its AJAX-y goodness has a serious flaw that has manifested itself in at least two sites I can think of who should know better (Slashdot, and Facebook).

Its a flaw that's occurred before, when developers were doing all sorts of stuff to open new windows or tabs to try to keep people in their site.

It's a flaw that targets the basic tennants of the web, its sole reason for existence, and its virtue in simplicity.

The flaw? Leave my browser's back and foward buttons alone. Let them do as they have always been intended - to take me back to a previous page location so I can maintain the context I was in previously. Slashdot violates this with its AJAXy "more stories" crap, so does Facebook. No one seems to be pointing this issue out to any sites who create these silly "Web 2.0" interfaces. And why the hell not?

I'm all for moving forward and improving the UX with AJAX, but don't take away the fundamental elements of a UX in the process. It's quite simple.

Author is "excited" about software tools? Sad. (0)

Anonymous Coward | about 4 years ago | (#31892672)

Is it just me, or does the author of this story sound like he is in love with making things as complicated as possible and is always using the newest technology because it is the newest and that somehow makes it best? Seriously, who gets "excited" about the tools you use for developing apps?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...