tools for programming applets

[Lew]

horos22 wrote:

Attribution restored (shame on you, horos22!)

Josuha,

That's not how his name is spelled.

I understand that this is a security risk - if used in production
systems. But as a development tool, it's invaluable.

As a development tool, a copy of the server environment is what's invaluable.
What you ask is unnecessary and harmful.

Something smells bad about your setup, horos22. You can't fake a development
environment with heinous security hacks. What's actually going on? Come on,
you can tell us. We won't snitch.

Consider protocol development. When I develop a ssh client, or mysql
client, or iscsi client, I don't need to make a new server instance or
somehow have to duplicate the server environment. The tests are

Yes, you do. You are so wrong here. Of course you work in a duplicate
environment. Development directly in the production environment is stupid,
risky, unprofessional, idiotic, untoward, and really not recommended.

*client* driven. I change the client, and as long as the protocol
works, I can make whatever changes I want behind the scenes without
touching *anything* except the source code on the client.

But you aren't asking to change a *client* [sic]. You're asking to change a
server. But you don't want to do it safely, properly or ethically. Doesn't
smell right, in the sense that Stilton cheese left outin late August in El
Paso doesn't smell right.

Suppose you had 10 developers working on an applet. What are they
supposed to do? Duplicate the parent environment 10 separate times?

YES!

Duhhh.

Why not? Why do you seem so frelling horrified by that perfectly sensible and
common and proper approach?

Hm?

What if the central environment changes? Do you then need to propogate
those changes to all 10 daughter environments? what if two people want
to merge changes or then test their changes our versus production
data? Do they need then to impact production by having their applet
hosted in the production world?

This makes no sense. I can't believe there isn't something out there

What you suggest makes no sense, and is harmful.

to do this. Unix has a permissions system and its invaluable - you

and was not developed on the production box.

open up the permissions on things to do development, get stuff done,
and then close down the permissions when you ship. There's gotta be a
way to overcome the extreme development penalty inherent in cloning

That's rich, "extreme development penalty" for the safest, most common and
proper way to go. Hahaha. ROTFLMAO.

environments here; elsewise I feel damn sorry for the java [sic] applet
developer..

Get over it. I certainly don't feel sorry for you.

Do start attributing citations, please. Have you not posted to Usenet before,
horos22?

 

[Lew]

YES! Of course. Duhh.

Hm.. a quick rsync comand. Plus:

1. an extra box for hosting the server
2. installs of any centralized tools (mysql, etc)
3. copying of production data
4. porting of the server web setup to my client
5. the need to reflect any changes that production makes.
6. Any cross-platform changes necessary in going from linux server to
a microsoft client.

You've GOT to be kidding me.

Actually, horos22, Lawrence's suggestion is sensible. It's called a
"programming environment", an essential part of any disciplined process and of
professional programming generally. Programming is hard, skilled work that
requires effort. Get used to it.

 

[markspace]

Hm.. a quick rsync comand. Plus:

1. an extra box for hosting the server
2. installs of any centralized tools (mysql, etc)
3. copying of production data
4. porting of the server web setup to my client
5. the need to reflect any changes that production makes.
6. Any cross-platform changes necessary in going from linux server to
a microsoft client.

Plus:

7. Actually investigating the user requirements so that an adequate and
focused test harness can be developed.

"Write your tests first."

When hasn't this been a normal part of software development? Seriously,
I'm not trying to beat you down or anything, but you're kinda talkin'
crazy here.

*Just* copying the user environment isn't enough. You have to go beyond
that to test your software. It's a lot more work than just making a
copy. Why is copying some data over and setting up a couple of servers
on a local machine considered a lot of work?

 

[Lew]

Plus:

7. Actually investigating the user requirements so that an adequate and
focused test harness can be developed.

"Write your tests first."

When hasn't this been a normal part of software development? Seriously, I'm
not trying to beat you down or anything, but you're kinda talkin' crazy here.

*Just* copying the user environment isn't enough. You have to go beyond that
to test your software. It's a lot more work than just making a copy. Why is
copying some data over and setting up a couple of servers on a local machine
considered a lot of work?

I just cannot buy that this is the real reason. The argument from horos22 is
too nonsensical and whiny. I deeply suspect that horos22 ("Ed") is up to
something and trying to make it seem reasonable, plus he's been going on and
on and on about how horrible the answer is instead of dealing with the answer.
What is horos22 really after? Inquiring minds want to know. It just
doesn't seem from here like horos22 is doing something proper and aboveboard;
rather it appears that he's up to something shady and dishonest.

 

[markspace]

I understand that this is a security risk - if used in production
systems. But as a development tool, it's invaluable.

I'd like to turn that around on you and ask you what development
environments you've used that didn't require you to build a test harness
before, during and after software development?

I don't think I've ever worked in one that did, to any reasonable or
useful degree. Not planning ahead for the test harness is, and I'm not
being mean here but simply being frank, the mark of a very inexperienced
software developer.

Consider protocol development. When I develop a ssh client, or mysql
client, or iscsi client, I don't need to make a new server instance or
somehow have to duplicate the server environment.

Seriously: I need to make a new server for testing, for each and every
one of these. How do you get by with out it?

The tests are
*client* driven. I change the client, and as long as the protocol
works, I can make whatever changes I want behind the scenes without
touching *anything* except the source code on the client.

What do you use to simulate the connection to the server when testing
your changes to the client?

Suppose you had 10 developers working on an applet. What are they
supposed to do? Duplicate the parent environment 10 separate times?

Yes, although this is a good time to put one person in charge of the
engineering test harness and propagate it out to all engineers. Also,
planning and coordination are required so that one engineer doesn't
duplicate work of other engineers, and that additions to the test
harness are useful and understood by all other engineers.

Useful tools here are revision control that can do the grunt work of
propagating changes out of a central repository.

What if the central environment changes? Do you then need to propogate
those changes to all 10 daughter environments? what if two people want
to merge changes or then test their changes our versus production
data?

See revisions control above.

Do they need then to impact production by having their applet
hosted in the production world?

No, that's why you clone the production environment to a test harness.

This makes no sense. I can't believe there isn't something out there
to do this. Unix has a permissions system and its invaluable - you
open up the permissions on things to do development, get stuff done,
and then close down the permissions when you ship.

I've you're talking about changing production systems in-place just by
giving yourself elevated permissions ... that's just crazy. Only the
simplest changes should be made like this, like installing software
that's already developed.

Sorry, but again it simply appears to me that you don't have a lot of
experience with software development. Take some advice: you got bit the
first time because you didn't know. Next time, figure into your
planning the need to develop a rigorous test environment. In general,
it adds about 2x effort to the software development (so total time is 3x).

There's gotta be a
way to overcome the extreme development penalty inherent in cloning
environments here;

When you find it let us know.

 

[markspace]

I guess I could use a little more detail here since I really am not
familiar with applet development or programming.

What kind of programming are you familiar with? It might help us point
out where things are different.

Do you have a good
pointer to a decent resource on the subject, say for setting this up
with apache?

Start here, especially the part about deploying an applet:

My client that I'm going to be working on is totally separate from the
server. Hopefully, I'm going to be doing development locally, and
then, when done, uploading the code changes to the server. If there is
a simple applet directive that I could put in a test page that could
take the code from localhost and run it against data that is hosted on
the server, then that is exactly what I need.

There really isn't. I need to turn this around and ask: what "data" are
you trying to pull from the server? SQL? Raw files? Some other
network protocol, SOAP perhaps? Something else entirely?

I think we need to get beyond this "simple directive" nonsense and try
to deal with the actual problem. Direct routes are often the most simple.

 

[markspace]

I just cannot buy that this is the real reason.

I think it is. There are a couple of tools that let you replace CSS on
an HTML page. The page design folks use them to mock up new pages or
fix errors before propagating back to the server.

He's just assuming that applets are like HTML. It's a rookie maneuver,
nothing more.

 

[Tom Anderson]

All what I have seen so far for demos written in Javascript and HTML5
are child like little toy applications compared to what can be done with
Java applets, today.

http://bellard.org/jslinux/

tom

 

[Joshua Cranmer]

Josuha,

While I am used to the spelling and/or pronunciation of my last name
being butchered, this is the first time in quite a while that I've seen
my first name incorrectly spelled ;-)

I understand that this is a security risk - if used in production
systems. But as a development tool, it's invaluable.

From a security risk, how would you lock it down in the production
system yet keep it available in development? By the time you start
trying to come up with mechanisms to allow that, you're not saving
yourself any effort compared to just making a new server or hosting
another install in a similar environment.

Consider protocol development. When I develop a ssh client, or mysql
client, or iscsi client, I don't need to make a new server instance or
somehow have to duplicate the server environment.

Applets aren't exactly like an SSH client. While I'm not exactly sure
what your use-case it is, it seems to me that the applet is acting more
like a smart client that does middleware business management-y stuff; a
close analogue to this would be an intranet application.

Suppose you had 10 developers working on an applet. What are they
supposed to do? Duplicate the parent environment 10 separate times?

When I worked on an intranet project, that is precisely what we did.
Everything from the copy of code we ran to the LDAP and MySQL databases
we authenticated against were created as separate copies for every
developer.

What if the central environment changes? Do you then need to propogate
those changes to all 10 daughter environments? what if two people want
to merge changes or then test their changes our versus production
data? Do they need then to impact production by having their applet
hosted in the production world?

Yes to your first question; no to your second. It is possible to
directly copy the production values to the non-production stuff.

This makes no sense. I can't believe there isn't something out there
to do this. Unix has a permissions system and its invaluable - you
open up the permissions on things to do development, get stuff done,
and then close down the permissions when you ship. There's gotta be a
way to overcome the extreme development penalty inherent in cloning
environments here; elsewise I feel damn sorry for the java applet
developer..

From my perspective, when hosting a webservice (including applets), one
key thing you need to be sure of is that you do not treat the
development testbed as the production environment. What happens if you
accidentally introduce a security leak for debugging purposes? The
entire world would see it in the production, while the development
version remains (theoretically) locked down within a corporate firewall.

 

[Lawrence D'Oliveiro]

In message

Hm.. a quick rsync comand. Plus:

1. an extra box for hosting the server

Run it on your development machine.

2. installs of any centralized tools (mysql, etc)

Would all be copied across with the rsync.

3. copying of production data

Again, would be done as part of the rsync.

4. porting of the server web setup to my client

Again, done by the rsync.

5. the need to reflect any changes that production makes.

Rsync again.

Did you know rsync is smart? If you run it against a previous copy, it will
only transfer the changes. This even applies to incremental changes to large
files. How can you compare two large files across a network connection
without copying most or all of one to the other side?

That was the subject of Andrew Tridgell’s PhD thesis.

6. Any cross-platform changes necessary in going from linux server to
a microsoft client.
Microsoft??

You've GOT to be kidding me.

Microsoft?? No, YOU’RE the one kidding me.

 

[Lawrence D'Oliveiro]

Yeah, you can now run Linux in a Javascript interpreter, but that is an
extremely recent development made possible by the turbo-charged
Javascript interpreters now available in the modern browsers.

Ah, so you noticed the “modern†part of all this new-fangled technology.

And honestly, I agree that Java applets can do *a lot* more.

Soon as you figure out how to apply the word “modern†to Java, I guess...

Why do you think JavaScript/DHTML/AJAX has grown by leaps and bounds, while
Java, which in some ways was a pioneer of the dynamic Web, has stagnated?

 

[Lawrence D'Oliveiro]

I'd like to turn that around on you and ask you what development
environments you've used that didn't require you to build a test harness
before, during and after software development?

When I build a major system, I like to build in the ability to run it in
“test modeâ€. This is a simple boolean flag which causes the code to read its
configuration file from a different directory, open the test database
instead of the production one, listen on a different port from the
production one, generate URLs linking to test areas of the website instead
of production areas, and so on.

I even wrote a custom Python installation script, which looks for a line
like this

test_mode = True/False

and edits it to have the right value depending where the script is going to
be installed.

Then I can run test and production systems side by side on the same server,
guaranteeing identical configurations for both. I can kill and restart test
processes without affecting anything important. I can selectively copy
across data from the production database to the test one. And once I’m
satisfied it’s up to production quality, it’s easy enough to arrange a time
with the users to upgrade the production system.

 

[Joshua Cranmer]

Why do you think JavaScript/DHTML/AJAX has grown by leaps and bounds, while
Java, which in some ways was a pioneer of the dynamic Web, has stagnated?

Why do you insist on bashing Java in a Java newsgroup?

To be fair, none of the technologies you mention has really made "leaps
and bounds". AJAX, or rather XHR (the underlying technology), itself was
specified several years back and hasn't been modified (to my knowledge)
since the introduction of the cross-origin specifications, which is more
or less incidental to the actual spec. JavaScript itself has had no more
fundamental changes than Java has had. As far as I can see, the only
truly new things (i.e., not present in any implementation for some time)
were the introduction of functional methods to Array, i.e., arr.forEach,
arr.filter, etc.

The only technologies that have really changed are the DOM, in
particular the introduction of <canvas>, web storage, and ... I think
that's about the only major interoperable new thing. SVG doesn't count
since it's been around for eons, nor does <video> since it's actually
worthless as no single format will be accepted by >75% of the browser
market. I'll also leave out CSS changes, since most of those are pretty
much either pie-in-the-sky experiments or attempting to sanely specify
what browsers already do.

Now, let me end by pointing out that Java has been able to do all of
these things for over a decade. That's right, all of these growing "by
leaps and bounds" is merely trying to get CSS/DOM/HTML up to the same
level of support that Java has already had since version 1.0. And there
are still things that Java can do that this approach is having problems
with--case in point number 1, designing traditional UI (i.e., flexing
models for layout). Java doesn't need to grow by leaps and bounds
because it already is a mature, working facility ... unlike the current
Web 2.0/3.0 stuff.

 

[markspace]

Then I can run test and production systems side by side on the same server,
guaranteeing identical configurations for both.

This is an interesting idea. I hadn't considered running a test system
on a production server, but it makes sense, I think, in some cases, to
be able to test the new system "in place," so that things don't go wrong
when you try to do a big change-over to a new system.

 

[John B. Matthews]

When I build a major system, I like to build in the ability to run it
in “test modeâ€. This is a simple boolean flag which causes the code
to read its configuration file from a different directory, open the
test database instead of the production one, listen on a different
port from the production one, generate URLs linking to test areas of
the website instead of production areas, and so on.

I even wrote a custom Python installation script, which looks for a
line like this

test_mode = True/False

and edits it to have the right value depending where the script is
going to be installed.

Then I can run test and production systems side by side on the same
server, guaranteeing identical configurations for both. I can kill
and restart test processes without affecting anything important. I
can selectively copy across data from the production database to the
test one. And once I’m satisfied it’s up to production quality, it’s
easy enough to arrange a time with the users to upgrade the
production system.

Some care must be taken to ensure that arbitrarily large portions of
test code are not retained by the system if an arbitrarily small change
can restore its accessibility. This is particularly so if the test code
weakens security for testing. Certain kinds of so-called "crippleware"
are an example:

<http://en.wikipedia.org/wiki/Damaged_good>

 

[Lew]

Why do you insist on bashing Java in a Java newsgroup?

To be fair, none of the technologies you mention has really made "leaps and
bounds". AJAX, or rather XHR (the underlying technology), itself was specified
several years back and hasn't been modified (to my knowledge) since the
introduction of the cross-origin specifications, which is more or less
incidental to the actual spec. JavaScript itself has had no more fundamental
changes than Java has had. As far as I can see, the only truly new things
(i.e., not present in any implementation for some time) were the introduction
of functional methods to Array, i.e., arr.forEach, arr.filter, etc.

The only technologies that have really changed are the DOM, in particular the
introduction of <canvas>, web storage, and ... I think that's about the only
major interoperable new thing. SVG doesn't count since it's been around for
eons, nor does <video> since it's actually worthless as no single format will
be accepted by >75% of the browser market. I'll also leave out CSS changes,
since most of those are pretty much either pie-in-the-sky experiments or
attempting to sanely specify what browsers already do.

Now, let me end by pointing out that Java has been able to do all of these
things for over a decade. That's right, all of these growing "by leaps and
bounds" is merely trying to get CSS/DOM/HTML up to the same level of support
that Java has already had since version 1.0. And there are still things that
Java can do that this approach is having problems with--case in point number
1, designing traditional UI (i.e., flexing models for layout). Java doesn't
need to grow by leaps and bounds because it already is a mature, working
facility ... unlike the current Web 2.0/3.0 stuff.

To use Lawrence's logic, we should hire him instead of you because your
knowledge is mature and stable, and not growing as quickly as his presumably
is at his stage of development as a programmer. Or, alternatively, we should
elect an infant as the nation's leader because their brain is growing so much
faster than a mature adult's.

This leaving out the fallacy that Java has stagnated, a blazingly false
assertion that Lawrence made with, as is usual for Lawrence, absolutely zero
evidence cited (as if there were any) or reasoning proffered.

So, Lawrence, care to provide any actual factual or evidentiary basis for your
apparent attempt to foment a flame war, Lawrence? We're waiting breathlessly,
Lawrence.

Aaaany time now, Lawrence.

 

[Lew]

This is an interesting idea. I hadn't considered running a test system on a
production server, but it makes sense, I think, in some cases, to be able to
test the new system "in place," so that things don't go wrong when you try to
do a big change-over to a new system.

Sure, as long as you don't bring down the production server to do your tests.

So many tests require a stable, re-creatable environment, and often that
involves hard or soft server restarts. If there are performance or security
requirements imposed on the server, having test stuff on there almost
certainly will violate them. Load testing? Ha!

Really, not a very good idea to put tests on the production server. Actually,
a really terrible, terrible idea. Ghastly.

Most places I've worked would consider firing a person for even suggesting
such a thing.

 

[Lawrence D'Oliveiro]

Some care must be taken to ensure that arbitrarily large portions of
test code are not retained by the system if an arbitrarily small change
can restore its accessibility. This is particularly so if the test code
weakens security for testing.

So far that hasn’t happened; the functionality between test and production
systems has been identical in every way.

 

[Lawrence D'Oliveiro]

Why do you insist on bashing Java in a Java newsgroup?

I don’t have to; I just point out the facts, and leave others to get angry
about them.

JavaScript itself has had no more fundamental changes than Java has had.
As far as I can see, the only truly new things (i.e., not present in any
implementation for some time) were the introduction of functional methods
to Array, i.e., arr.forEach, arr.filter, etc.

Functions as first-class objects.

Now, let me end by pointing out that Java has been able to do all of
these things for over a decade.

And yet nobody was ever able to do them. Where is the Java equivalent of
jQuery, for example?

 

[markspace]

Really, not a very good idea to put tests on the production server.
Actually, a really terrible, terrible idea. Ghastly.

I wasn't thinking of doing the entire test suite, all through
development, on a production system. I was thinking of only doing just
a kind of final system test. After the product is deemed stable, you
install it on production server, with out removing the old system. Then
you can quickly switch back to the old system if the new system fails
for some reason.

The real issue with testing both production and development on the same
box would be resources. CPU time, memory: those are things that
production tends not to be able to spare. So this would have to be
carefully planned out.

But running the old system and the new, at the same time, in parallel,
sounds like it might allow one to do an "instant" deployment, at least
in some circumstances.