how to deliver a GUI app to an end user

[ccc31807]

This has a bit of history behind it, which I won't relate at the cost
of possibly misleading you. The process is a large, critical process,
consisting of the preparation and delivery of several thousand vendor
contracts five times a year. My previous involvement has been on the
back end, furnishing the data files for the 'end user' to use for
preparation of the contracts.

Due to a number of changes, including personnel changes, major new
requirements, hiring freezes, software obsolescence, purchase order
holds, and license restrictions, we (read 'I') have a problem and it
seems beyond my ability to solve.

I had written (several years ago) three Perl scripts running on the
CLI, the first querying the database and munging the data, the second
preparing the individual contracts as PDFs, and the third delivering
the contracts to the vendors. Only the first script was used, since
the people responsible used a point and click application to prepare
and email the contracts. (Alpha 5 was the software used.)

As a result of the changes mentioned, I dusted off the scripts I had
written, revised them to meet the new requirements, and they work
flawlessly, meeting the new requirements to perfection, and (being
automated) do the job in a fraction of a second without error
(previously took a couple of days and was error prone.) It's ready to
roll.

Here's the problem: the employee charged with the contracting process
is not capable of running scripts from the CLI, but can only point and
click, and besides, cannot (due to IA policy) install Perl on her
machine. Due to policy, I'm not allowed to run end user processes,
such as the preparation of the contracts.

I've toyed with the idea of rewriting the app in Java, or perhaps
using .NET to build a graphical interface to the Perl scripts, but
this isn't my area and I really don't want to do this. I also toyed
with the idea of putting the whole thing on a web server and giving
her access through a browser, but that's probably a violation of IA
policy as well (never mind the fact that it will be on the intranet.)

Ideas?

Thanks, CC.

 

[Peter J. Holzer]

Here's the problem: the employee charged with the contracting process
is not capable of running scripts from the CLI, but can only point and
click, and besides, cannot (due to IA policy) install Perl on her
machine. Due to policy, I'm not allowed to run end user processes,
such as the preparation of the contracts.

Must this program run on the user's machine?

* If not: How about running them on the server and putting a
minimalistic Web GUI in front of it?
* If yes, is there a policy against perl specifically or against
unauthorized software in general?

hp

 

[John Bokma]

The most obvious is PAR. This will give you a single binary which can be
deployed to the end-user. The disadvantages are that the unpacking
process can be a little slow (though with modern machines this isn't a
problem, IME) and that, particularly with toolkits like Wx that use
clever dynamic loading tricks, it can be sometimes be tricky to get the
app packed correctly. The (e-mail address removed) list is generally helpful when
problems arise.

For Perl programs that use Wx I use wxpar, see Wx-Perl-Packager on CPAN.

 

[ccc31807]

Must this program run on the user's machine?

The accepted paradigm is for the Alpha 5 software to run on the
individual's machine that is responsible for sending out the
contracts. This is an entirely separate division, not IT, and the rule
for that department is only Windows apps (Office) and things
ordinarily on a users machine, such as the JVM and .NET runtimes.

* If not: How about running them on the server and putting a
  minimalistic Web GUI in front of it?
* If yes, is there a policy against perl specifically or against
  unauthorized software in general?

Both. Perl is disfavored because it is 'insecure' in the sense that
one can write programs in Perl -- it's really a situation of ignorance
on the part of the managers.

CC

 

[ccc31807]

The most obvious is PAR. This will give you a single binary which can be
deployed to the end-user. The disadvantages are that the unpacking
process can be a little slow (though with modern machines this isn't a
problem, IME) and that, particularly with toolkits like Wx that use
clever dynamic loading tricks, it can be sometimes be tricky to get the
app packed correctly. The (e-mail address removed) list is generally helpful when
problems arise.

I've just toyed with PAR, it looked like too much work at the time for
the expected benefit, so I wasn't real interested.

The next most obvious is simply to install perl on your machine, install
any required modules and a front-end script (possibly converted into an
exe with the appropriate pp invocation), and then pack the whole
directory tree up in a tarball and call it a custom app. If this is a
Win32 app (I believe it is?) it is also fairly straightforward to wrap
that tarball in a 'proper' installer, using the NSIS kit, though under
normal circumstances it won't be possible to customize the install
directory at install time and the compiled-in directory mustn't have any
spaces in its path, which may make admins nervous.

I've actually used NSIS to enable updates on non-networked machines,
and (unlike PAR) I do have an interest in learning more about NSIS.
This might be a solution.

After that, I think at the moment you're into pay-for solutions. AS
provide various tools, some of which I think may do what you want; I've
never used any of them so I can't comment.

My solution was to buy the new version of Alpha 5 and continue to use
that. Unfortunately, the guy (a non-IT, professional employee) who
originally developed the process has moved beyond this, and I would be
the one to redevelop the application. The good part is that I believe
Alpha 5 to be a respectable piece of work and I would consider it a
benefit to learn more about it.

Of course, you could always help me finishhttp://github.com/mauzo/ExtUtils-PerlToExe, but given that I haven't
worked on it for a while and there are more than a few important
unsolved problems I don't know that I'd recommend it...

I've felt for a long time that the ability to easily generate machine
code from Perl would be a big benefit for the community. I've been
playing with Common Lisp for several years now (as and when I have the
spare time) and I'm really attracted by the fact that:
- you can compile CL into native machine code without having to do
memory management or deal with pointers,
- you can target your CL app to the JVM with ABCL or Clojure, and
- you can achieve very fast code without too much work.

Thanks for your suggestions, CC.

 

[John]

hp

Are you the same Peter Holzer who was at the IHS in 1975?

Regards
John

 

[C.DeRykus]

...
I had written (several years ago) three Perl scripts running on the
CLI, the first querying the database and munging the data, the second
preparing the individual contracts as PDFs, and the third delivering
the contracts to the vendors. Only the first script was used, since
the people responsible used a point and click application to prepare
and email the contracts. (Alpha 5 was the software used.)

As a result of the changes mentioned, I dusted off the scripts I had
written, revised them to meet the new requirements, and they work
flawlessly, meeting the new requirements to perfection, and (being
automated) do the job in a fraction of a second without error
(previously took a couple of days and was error prone.) It's ready to
roll.

Here's the problem: the employee charged with the contracting process
is not capable of running scripts from the CLI, but can only point and
click, and besides, cannot (due to IA policy) install Perl on her
machine. Due to policy, I'm not allowed to run end user processes,
such as the preparation of the contracts.

I've toyed with the idea of rewriting the app in Java, or perhaps
using .NET to build a graphical interface to the Perl scripts, but
this isn't my area and I really don't want to do this. I also toyed
with the idea of putting the whole thing on a web server and giving
her access through a browser, but that's probably a violation of IA
policy as well (never mind the fact that it will be on the intranet.)

Could you dodge IA's minefields by installing PuTTY on the end user's
PC..(if it's not already)? The scripts' permissions could be altered
to be runnable only by a particular acct/pw accessible to the end
user.
This'd eliminate the need to transport/install Perl locally and access
would at least occur over a secure channel.

 

[ccc31807]

Could you dodge IA's minefields by installing PuTTY on the end user's
PC..(if it's not already)?  The scripts' permissions could be altered
to be runnable only by a particular acct/pw accessible to the end
user.

There are two issues here, both created by idiots. The first is the
prejudice against CLI applications, and I've been explicitly told not
to give non-IT users CLI scripts because they are incapable of running
them. PuTTy would fall into this category.

The second issue is a non-IT issue, namely the prejudice business
types have against in-house apps, not just Perl, but anything they
haven't paid a lot of money for purchased from a big company (like
Microsoft or Adobe or IBM.)

After sleeping on it, I think I'm going to recommend three courses of
action:
1 - Accept the solution I created, CLI and all.
2 - Bite the bullet and purchase licenses for the updated third party
software.
3 - Contract out the project to an independent developer.

It amazes me sometimes that non-functional requirements trump
functional requirements, and even if your app works perfectly and
completely meets all the functional requirements, it's rejected
because of some non-functional requirement that was neither explicitly
stated nor implicit in the original specification. It's as if you have
the fastest (by far) car in the race, but you lose the prize after the
fact because your car wasn't green.

And yeah, I'm pretty disgusted by the whole exercise.

CC.

 

[ccc31807]

This is not stupid.

Actually, I was only venting. I know that they're not idiots -- they
just have a different frame of reference, and I can deal with that.
However, using the word 'idiot' sometimes has a desirable paradigm
changing effect, provided the technique isn't over used.

Even if you provided a curses-type 'gui', I suspect
most ordinary users would find being unable to use the mouse unbearably
confusing.

You are 100% correct. However, if an employee holds himself or herself
out of have specific skills, you get to rely on the representations of
the employee.

The reasoning behind this (wanting to avoid liability, by ensuring
someone has a contract) is not stupid, but too many people fail to
realize just how little in the way of safety their expensive contracts
are buying them. This is not helped by people like us dismissing the
whole concern out of hand.

I agree, but would add that a large part of it is ignorance, that is,
not understanding a technology. People tend to be afraid of what they
don't understand, but there's a difference between dealing with
something you don't understand by trying to understand it, and dealing
with it by shoving your head in the sand and your arse into the
sunlight.

'Can be used by the intended user' is always an implicit functional
requirement.

I agree 100%. See below.

It's part of your job as a
programmer to anticipate these unspoken requirements, since you
understand the problem better than those giving you the spec.

This depends on what 'your job' is. As it happens, my job is NOT to
build GUIs that allow lay people to work easily. My job is to support
the line staff by giving them the information they need to do their
job. It's not up to me to tell them what information they need, what
their job is, or how to use the information to do their job.

<rant>I'm allowed to squeal when required to perform some needless
piece of insanity when someone else is not competent to perform their
assigned duties.</rant>

I also understand that being a valued member of a team, and a
professional, requires one to set aside his personal feelings and
prejudices and to work to assist the other team members in the joint
effort. I'm not being mean or selfish or derogatory, just exercising
my (earned) right to voice my feelings in a place where I can get away
with it.

Thanks, CC.

 

[QoS]

This has a bit of history behind it, which I won't relate at the cost
of possibly misleading you. The process is a large, critical process,
consisting of the preparation and delivery of several thousand vendor
contracts five times a year. My previous involvement has been on the
back end, furnishing the data files for the 'end user' to use for
preparation of the contracts.

Due to a number of changes, including personnel changes, major new
requirements, hiring freezes, software obsolescence, purchase order
holds, and license restrictions, we (read 'I') have a problem and it
seems beyond my ability to solve.

I had written (several years ago) three Perl scripts running on the
CLI, the first querying the database and munging the data, the second
preparing the individual contracts as PDFs, and the third delivering
the contracts to the vendors. Only the first script was used, since
the people responsible used a point and click application to prepare
and email the contracts. (Alpha 5 was the software used.)

As a result of the changes mentioned, I dusted off the scripts I had
written, revised them to meet the new requirements, and they work
flawlessly, meeting the new requirements to perfection, and (being
automated) do the job in a fraction of a second without error
(previously took a couple of days and was error prone.) It's ready to
roll.

Here's the problem: the employee charged with the contracting process
is not capable of running scripts from the CLI, but can only point and
click, and besides, cannot (due to IA policy) install Perl on her
machine. Due to policy, I'm not allowed to run end user processes,
such as the preparation of the contracts.

I've toyed with the idea of rewriting the app in Java, or perhaps
using .NET to build a graphical interface to the Perl scripts, but
this isn't my area and I really don't want to do this. I also toyed
with the idea of putting the whole thing on a web server and giving
her access through a browser, but that's probably a violation of IA
policy as well (never mind the fact that it will be on the intranet.)

Ideas?

Thanks, CC.

This works: http://www.activestate.com/perl_dev_kit/

J