Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > tools for programming applets

Reply
Thread Tools

tools for programming applets

 
 
Lew
Guest
Posts: n/a
 
      05-22-2011
horos22 wrote:

Attribution restored (shame on you, horos22!)
Joshua Cranmer wrote:
>> Java applets were designed to be as secure as possible. Hence why, for
>> example, they are forbidden from opening a network connection to
>> anywhere other than their source domain. Allowing you to replace your
>> own applet to run in another's context domain is a recipe for security
>> holes; in principle, you could allow the server to list other applets
>> that can run in their domain (in similarity to how CORS stuff works),
>> but that is essentially the same level of changes needed as hosting
>> another copy of the applet.
>>
>> --


> 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
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      05-22-2011
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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
 
 
 
markspace
Guest
Posts: n/a
 
      05-22-2011
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?

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      05-22-2011
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/wikipedi.../c/cf/Friz.jpg
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      05-22-2011
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.

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      05-22-2011
On 5/22/2011 5:30 AM, horos22 wrote:

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

<http://download.oracle.com/javase/tutorial/deployment/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.



 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      05-22-2011
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.

 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      05-22-2011
On Sat, 21 May 2011, Nasser M. Abbasi wrote:

> 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

--
It's not even just bad. It's Waterworld bad, it's Iraq-occupation bad,
it's '62 Mets bad. -- robotslave
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      05-22-2011
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
 
Reply With Quote
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      05-23-2011
In message
<(E-Mail Removed)>, horos22
wrote:

> On May 21, 8:38 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> In message
>> <(E-Mail Removed)>,
>> 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


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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: tools for programming applets horos22 Java 2 05-23-2011 11:01 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui C++ 0 04-27-2009 12:51 PM
3 ESSENTIAL TOOLS FOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLSFOR STARTING AND MAINTAINING...3 ESSENTIAL TOOLS FOR STARTING ANDMAINTAINING... Oanh Bui Python 0 04-27-2009 12:46 PM
Article : Security Tools Part -- 2 (.Net FrameWork Tools Series) Namratha Shah \(Nasha\) ASP .Net 0 11-23-2004 04:01 PM



Advertisments