Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #4364 > unrolled thread

tools for programming applets

Started byhoros22 <ed.peschko@gmail.com>
First post2011-05-20 14:43 -0700
Last post2011-05-26 16:37 +0000
Articles 20 on this page of 90 — 19 participants

Back to article view | Back to comp.lang.java.programmer


Contents

  tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-20 14:43 -0700
    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-21 09:57 +1200
      Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-20 18:27 -0400
      Re: tools for programming applets "Richard Maher" <maher_rj@hotspamnotmail.com> - 2011-05-21 08:56 +0800
      Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-20 21:28 -0400
        Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-22 11:11 +1200
      Re: tools for programming applets markspace <-@.> - 2011-05-20 18:31 -0700
      Re: tools for programming applets "Nasser M. Abbasi" <nma@12000.org> - 2011-05-21 12:15 -0700
        Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-22 11:15 +1200
        Re: tools for programming applets Tom Anderson <twic@urchin.earth.li> - 2011-05-22 14:35 +0100
          Re: tools for programming applets Steve Sobol <sjsobol@JustThe.net> - 2011-05-22 08:12 -0700
            Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 12:26 +1200
              Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-22 20:59 -0400
                Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-22 22:01 -0400
                Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 14:17 +1200
                  Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-22 23:34 -0400
                    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 18:44 +1200
                      Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-23 09:13 -0400
                      Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-23 10:37 -0400
                        Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-24 20:15 +1200
                          Re: tools for programming applets Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-24 07:04 -0300
                            Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 14:14 +1200
                          Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-24 08:10 -0400
                  Re: tools for programming applets Stanimir Stamenkov <s7an10@netscape.net> - 2011-05-24 16:09 +0300
                    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-26 11:35 +1200
                      Re: tools for programming applets Stanimir Stamenkov <s7an10@netscape.net> - 2011-05-27 00:13 +0300
                        Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 18:50 +1200
                          Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-27 09:55 -0400
                            Re: tools for programming applets Michael Wojcik <mwojcik@newsguy.com> - 2011-05-27 11:31 -0400
                              Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-28 14:35 +1200
                                Re: tools for programming applets Steve Sobol <sjsobol@JustThe.net> - 2011-05-28 12:17 -0700
                                  Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-30 03:26 -0700
                                Re: tools for programming applets Michael Wojcik <mwojcik@newsguy.com> - 2011-06-03 08:19 -0400
    Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-20 18:29 -0400
    Re: tools for programming applets markspace <-@.> - 2011-05-20 16:11 -0700
      Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-20 20:12 -0400
        Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-21 09:10 -0700
          Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-21 12:55 -0400
            Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-22 05:18 -0700
              Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-22 08:37 -0400
              Re: tools for programming applets markspace <-@.> - 2011-05-22 05:58 -0700
                Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 12:34 +1200
                  Re: tools for programming applets markspace <-@.> - 2011-05-22 18:11 -0700
                    Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-22 22:06 -0400
                      Re: tools for programming applets markspace <-@.> - 2011-05-22 20:26 -0700
                  Re: tools for programming applets "John B. Matthews" <nospam@nospam.invalid> - 2011-05-22 21:31 -0400
                    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 14:14 +1200
                Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-23 08:31 -0700
                  Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-23 12:08 -0400
                    Re: tools for programming applets Silvio <silvio@moc.com> - 2011-06-19 14:43 +0200
                  Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 14:13 +1200
              Re: tools for programming applets Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-22 17:39 -0400
          Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-22 15:38 +1200
            Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-22 05:24 -0700
              Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-22 08:41 -0400
              Re: tools for programming applets markspace <-@.> - 2011-05-22 05:43 -0700
                Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-22 08:53 -0400
                  Re: tools for programming applets markspace <-@.> - 2011-05-22 06:15 -0700
                    Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-23 08:38 -0700
                      Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-23 12:17 -0400
                        Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-24 05:22 -0700
                          Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-24 08:38 -0400
                            Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-24 06:33 -0700
                              Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-25 12:06 +1200
                                Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-26 05:54 -0700
                                  Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 00:57 +1200
                                    Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-26 09:04 -0400
                                      Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-26 06:12 -0700
                                        Re: tools for programming applets Lew <noone@lewscanon.com> - 2011-05-26 09:28 -0400
                                        Re: tools for programming applets Steve Sobol <sjsobol@JustThe.net> - 2011-05-26 14:47 -0700
                                  Re: tools for programming applets Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-26 13:51 +0000
                                    Re: tools for programming applets Alessio Stalla <alessiostalla@gmail.com> - 2011-05-26 07:38 -0700
                                      Re: tools for programming applets Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-26 15:23 +0000
                                      Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 14:10 +1200
                                    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 14:11 +1200
                                      Re: tools for programming applets Martin Gregorie <martin@address-in-sig.invalid> - 2011-05-27 14:47 +0000
                            Re: tools for programming applets Steve Sobol <sjsobol@JustThe.net> - 2011-05-24 10:07 -0700
                      Re: tools for programming applets markspace <-@.> - 2011-05-23 11:27 -0700
              Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-23 12:23 +1200
                Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-23 08:50 -0700
                  Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-24 14:45 +1200
                  Re: tools for programming applets Andrew Thompson <andrewthommo@gmail.com> - 2011-05-25 03:46 -0700
                    Re: tools for programming applets Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-27 14:12 +1200
    Re: tools for programming applets Roedy Green <see_website@mindprod.com.invalid> - 2011-05-21 09:31 -0700
    Re: tools for programming applets "Richard Maher" <maher_rj@hotspamnotmail.com> - 2011-05-22 08:05 +0800
      Re: tools for programming applets horos22 <ed.peschko@gmail.com> - 2011-05-22 05:30 -0700
        Re: tools for programming applets markspace <-@.> - 2011-05-22 06:05 -0700
    Re: tools for programming applets Silvio <silvio@moc.com> - 2011-05-24 12:30 +0200
      Re: tools for programming applets Michael Wojcik <mwojcik@newsguy.com> - 2011-05-26 14:29 -0400
    Re: tools for programming applets Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-26 16:37 +0000

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →


#4416

Frommarkspace <-@.>
Date2011-05-22 05:58 -0700
Message-ID<irb1aj$5qq$1@dont-email.me>
In reply to#4409
On 5/22/2011 5:18 AM, horos22 wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#4426

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-05-23 12:34 +1200
Message-ID<irca2d$5mc$1@lust.ihug.co.nz>
In reply to#4416
In message <irb1aj$5qq$1@dont-email.me>,  wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#4431

Frommarkspace <-@.>
Date2011-05-22 18:11 -0700
Message-ID<ircc92$jn8$1@dont-email.me>
In reply to#4426
On 5/22/2011 5:34 PM, Lawrence D'Oliveiro wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#4434

FromLew <noone@lewscanon.com>
Date2011-05-22 22:06 -0400
Message-ID<ircff9$fo0$1@news.albasani.net>
In reply to#4431
On 05/22/2011 09:11 PM, markspace wrote:
> On 5/22/2011 5:34 PM, Lawrence D'Oliveiro wrote:
>
>> 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.

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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]


#4438

Frommarkspace <-@.>
Date2011-05-22 20:26 -0700
Message-ID<irck5t$oea$1@dont-email.me>
In reply to#4434
On 5/22/2011 7:06 PM, Lew wrote:
> 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.

[toc] | [prev] | [next] | [standalone]


#4432

From"John B. Matthews" <nospam@nospam.invalid>
Date2011-05-22 21:31 -0400
Message-ID<nospam-A54319.21314822052011@news.aioe.org>
In reply to#4426
In article <irca2d$5mc$1@lust.ihug.co.nz>,
 Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

> In message <irb1aj$5qq$1@dont-email.me>,  wrote:
> 
> > 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.

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>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]


#4435

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-05-23 14:14 +1200
Message-ID<ircfv0$8k8$5@lust.ihug.co.nz>
In reply to#4432
In message <nospam-A54319.21314822052011@news.aioe.org>, John B. Matthews 
wrote:

> 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.

[toc] | [prev] | [next] | [standalone]


#4459

Fromhoros22 <ed.peschko@gmail.com>
Date2011-05-23 08:31 -0700
Message-ID<f8688cca-9ca1-44fb-83dc-65cd7be26950@17g2000prr.googlegroups.com>
In reply to#4416
Look guys,

I see that I caused a bit of a firestorm - which was not my intent -
and I see that people are attributing motives to me that are
completely baseless. (no - I'm not up to anything 'nefarious', no I'm
not trying to hack the pentagon.)

The site in question is not a large-scale, fully-funded site. It
doesn't - and I don't - have the financial means to fully duplicate
the environment just for the sake of doing testing and development.
Frankly, it's a not-for-profit and the work is also not-for-profit.

Furthermore, *no* I'm not talking about changing a production system
'in place' - in fact I'm making my best possible effort *not* to
change the production system.

By keeping things local - in just changes to the client (the applet),
and not writing back any data to the production system - I'm
guaranteeing that I'm keeping the production system intact.

In fact I'm doing better than that. If I can run tests against *real*
production data, I can make a better guarantee that the applet would
work better than just by regression tests alone.

Sheesh. I swear that developers (myself included) have been in this
industry SO LONG that they take for granted the bulky, resource
intensive, extra-life-support-systems-required effort that programming
has become.

Here's a clue - not everything developed has a requirement of
thousands of transactions per second, page views in the millions, and
teams of hundreds. And not every effort is capitalized in the millions
(or even thousands) of dollars.

So think small in answering this question, will you? It looks like -
from your responses - that I'll have to cobble something up on my
client to do the work. Or have the site administrator put a special
directive for my IP in the server to handle my testing, such that the
data comes from the server, but the applet comes from localhost.

And stop with the nefarious purposes line of thought.. ok? It isn't
conducive to reasoned conversation, and frankly it makes otherwise
intelligent people sound like conspiracy nuts.

Ed

[toc] | [prev] | [next] | [standalone]


#4466

FromLew <noone@lewscanon.com>
Date2011-05-23 12:08 -0400
Message-ID<ire0qc$999$1@news.albasani.net>
In reply to#4459
horos22 wrote:
> Look guys,
>
> I see that I caused a bit of a firestorm - which was not my intent -
> and I see that people are attributing motives to me that are
> completely baseless. (no - I'm not up to anything 'nefarious', no I'm
> not trying to hack the pentagon [sic].)
>
> The site in question is not a large-scale, fully-funded site. It
> doesn't - and I don't - have the financial means to fully duplicate
> the environment just for the sake of doing testing and development.
> Frankly, it's a not-for-profit and the work is also not-for-profit.
>
> Furthermore, *no* I'm not talking about changing a production system
> 'in place' - in fact I'm making my best possible effort *not* to
> change the production system.
>
> By keeping things local - in just changes to the client (the applet),

Applets are server-side, not clients.

> and not writing back any data to the production system - I'm
> guaranteeing that I'm keeping the production system intact.

You mean, other than by trying to circumvent its security.

> In fact I'm doing better than that. If I can run tests against *real*
> production data, I can make a better guarantee that the applet would
> work better than just by regression tests alone.

No one has yet suggested regression tests alone.  Where did that come from?

> Sheesh. I swear that developers (myself included) have been in this
> industry SO LONG that they take for granted the bulky, resource
> intensive, extra-life-support-systems-required effort that programming
> has become.

Irrelevant comment.  We were talking about applets and their security 
mechanism.  There's no "bulky, resource intensive, 
extra-life-support-systems-required effort that programming has become". 
There's only your irrational resistance to the facts.

> Here's a clue - not everything developed has a requirement of
> thousands of transactions per second, page views in the millions, and
> teams of hundreds. And not every effort is capitalized in the millions
> (or even thousands) of dollars.

What does that have to do with anything?\

To quote you, "Sheesh".  Get a grip.

> So think small in answering this question, will you? It looks like -
> from your responses - that I'll have to cobble something up on my
> client to do the work. Or have the site administrator put a special
> directive for my IP in the server to handle my testing, such that the
> data comes from the server, but the applet comes from localhost.

"Think small"?  Are you on drugs?  This isn't about scale, this is about 
applet security, which BY DESIGN prevents the heinous activity for which 
you're asking.  This is true small or large.

And having a testbed separate from the production server is not "large", 
doesn't mean "millions" or "gaziilions" or any other of that hyperbolic 
bullshit you're pooping out.

Sober up, take a deep breath, and approach your problem rationally, son.

> And stop with the nefarious purposes line of thought.. ok? It isn't
> conducive to reasoned conversation, and frankly it makes otherwise
> intelligent people sound like conspiracy nuts.

You kept fighting the truth and asking for a nefarious, security-circumventing 
technique even after your question was asked.  Maybe if you'd been more 
forthcoming initially, and less insulting right now, we'd have less basis to 
suspect your motives.  The conclusion was entirely rational based on the 
evidence you provided.  Your attempt to duck responsibility for that doesn't 
make anyone else look less intelligent, horos22 (not your real name).

So stop with the blaming us for your behavior, hm-K?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]


#5370

FromSilvio <silvio@moc.com>
Date2011-06-19 14:43 +0200
Message-ID<4dfdeed9$0$49046$e4fe514c@news.xs4all.nl>
In reply to#4466
On 05/23/2011 06:08 PM, Lew wrote:
>
> Applets are server-side, not clients.
>

Nonsense, an applet is a client. The only "server-side" thing about it 
is that it's code was delivered by a server. Following that reasoning an 
image or a any piece of JavaScript on a web page is also server side.

>
> You mean, other than by trying to circumvent its security.
>

An Applet has no security of it's own. Only when run as part of a web 
page does the user agent impose well defined limitations on the runtime 
running the untrusted Applet. This is done to protect the client system 
from being harmed by the Applet, not to protect the Applet from the 
outer world. As such the security is part of the user agent, not the Applet.

[toc] | [prev] | [next] | [standalone]


#4631

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-05-27 14:13 +1200
Message-ID<irn1bq$b7q$4@lust.ihug.co.nz>
In reply to#4459
In message 
<f8688cca-9ca1-44fb-83dc-65cd7be26950@17g2000prr.googlegroups.com>, horos22 
wrote:

> Sheesh. I swear that developers (myself included) have been in this
> industry SO LONG that they take for granted the bulky, resource
> intensive, extra-life-support-systems-required effort that programming
> has become.

Who said it did?

[toc] | [prev] | [next] | [standalone]


#4422

FromJoshua Cranmer <Pidgeot18@verizon.invalid>
Date2011-05-22 17:39 -0400
Message-ID<irbvqu$f99$1@dont-email.me>
In reply to#4409
On 5/22/2011 8:18 AM, horos22 wrote:
> 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.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]


#4400

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-05-22 15:38 +1200
Message-ID<ira0fj$qov$2@lust.ihug.co.nz>
In reply to#4385
In message
<d9f939a9-fddf-45df-9935-3bef2b11ed4f@r27g2000prr.googlegroups.com>, horos22 
wrote:

> You really want me to clone a database, web server,
> web configuration setup just to test one lousy applet?

Just a quick rsync command. How hard could it be?

[toc] | [prev] | [next] | [standalone]


#4410

Fromhoros22 <ed.peschko@gmail.com>
Date2011-05-22 05:24 -0700
Message-ID<ad83c954-5365-42cf-bbf6-c482d25c7cb3@r35g2000prj.googlegroups.com>
In reply to#4400
On May 21, 8:38 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message
> <d9f939a9-fddf-45df-9935-3bef2b11e...@r27g2000prr.googlegroups.com>, horos22
> wrote:
>
> > You really want me to clone a database, web server,
> > web configuration setup just to test one lousy applet?
>
> Just a quick rsync command. How hard could it be?

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.

Ed

[toc] | [prev] | [next] | [standalone]


#4413

FromLew <noone@lewscanon.com>
Date2011-05-22 08:41 -0400
Message-ID<irb0ad$adi$1@news.albasani.net>
In reply to#4410
horos22 wrote:
> Lawrence D'Oliveiro wrote:
>> horos22 wrote:
>>> You really want me to clone a database, web server,
>>> web configuration setup just to test one lousy applet?

YES!  Of course.  Duhh.

>> Just a quick rsync command. How hard could it be?

> 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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]


#4414

Frommarkspace <-@.>
Date2011-05-22 05:43 -0700
Message-ID<irb0el$fk$1@dont-email.me>
In reply to#4410
On 5/22/2011 5:24 AM, horos22 wrote:

> 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?

[toc] | [prev] | [next] | [standalone]


#4415

FromLew <noone@lewscanon.com>
Date2011-05-22 08:53 -0400
Message-ID<irb10j$c0h$1@news.albasani.net>
In reply to#4414
On 05/22/2011 08:43 AM, markspace wrote:
> On 5/22/2011 5:24 AM, horos22 wrote:
>
>> 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?

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.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]


#4418

Frommarkspace <-@.>
Date2011-05-22 06:15 -0700
Message-ID<irb2ab$8fg$2@dont-email.me>
In reply to#4415
On 5/22/2011 5:53 AM, Lew wrote:

>
> 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.

[toc] | [prev] | [next] | [standalone]


#4461

Fromhoros22 <ed.peschko@gmail.com>
Date2011-05-23 08:38 -0700
Message-ID<41dd1d4d-400b-4801-81cd-0136cc505faf@y27g2000prb.googlegroups.com>
In reply to#4418
On May 22, 6:15 am, markspace <-@.> wrote:
> On 5/22/2011 5:53 AM, Lew wrote:
>
>
>
> > 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.

Mark,

I think you get my drift, but I'd raise you one further. Albeit
insecure, there *should* be a way to replace applets like you would
replace CSS. It would make things a helluva lot simpler in
development. This shouldn't be turned on by default, but it should be
there.

BTW there are tons of things that sense for development purposes, that
make no sense for production deployment. Why this is any different is
beyond me.

Ed

[toc] | [prev] | [next] | [standalone]


#4467

FromLew <noone@lewscanon.com>
Date2011-05-23 12:17 -0400
Message-ID<ire1ar$aoj$1@news.albasani.net>
In reply to#4461
On 05/23/2011 11:38 AM, horos22 wrote:
> On May 22, 6:15 am, markspace<-@.>  wrote:
>> On 5/22/2011 5:53 AM, Lew wrote:
>>
>>
>>
>>> 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.
>
> Mark,
>
> I think you get my drift, but I'd raise you one further. Albeit
> insecure, there *should* be a way to replace applets like you would
> replace CSS. It would make things a helluva lot simpler in
> development. This shouldn't be turned on by default, but it should be
> there.
>
> BTW there are tons of things that sense for development purposes, that
> make no sense for production deployment. Why this is any different is
> beyond me.

No, there shouldn't.  How would an applet call back to the correct host if you 
have it mounted from localhost?  Applets are only allowed to get resources 
from their own server.

Your fundamental error in thought is that applets are not at all like CSS. 
CSS is a brower-interpreted, client-side phenomenon.  Applets are a JVM-run, 
server-side phenomenon that just happen to run out of a browser.  Big difference.

Now stop whining about your pathetic thoughts of how things "should" be and 
deal with reality as it actually is, or find a profession that doesn't require 
rational reasoning.  Or write your own technology to compete with applets. 
Just stop whining over and over and over and over and over and over about how 
you think in your infinite wisdom and genius that things should be different 
than they actually are.  You'll never get the job done that way.

It's pathetic.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]


Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.java.programmer


csiph-web