× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



"WDSCI-L" <wdsci-l-bounces@xxxxxxxxxxxx> wrote on 04/20/2017 08:03:36 AM:
----- Message from "Edmund Reinhardt" <edmund.reinhardt@xxxxxxxxxx>
on Wed, 19 Apr 2017 18:20:57 -0400 -----

To:

Rational Developer for IBM i / Websphere Development Studio Client
for System i & iSeries <wdsci-l@xxxxxxxxxxxx>

cc:

Rob Cecco <cecco@xxxxxxxxxx>

Subject:

[WDSCI-L] Feedback on iProjects - good, bad and ugly

As RDi architect, I want to make sure that I don't get out of touch with
your experience in using RDi in the trenches.
For example, I might think that i Projects are a perfect way for people
to
be able to use Git on IBM i and maybe I am missing some reason why
people
are not adopting i Projects.
So please set me straight.
Who is using i Projects and if so how do you like it?
If you have tried i Projects and abandoned them, let me know why?

I am very thankful to have access to such a vocal group of customers
that I
can get unfiltered, immediate feedback from.

Thanks
Edmund

Edmund,

Thanks once again for your interest in making RDi such a great product for
those of us that use it. I don't even want to try to imagine working
without RDi. Anyway at the risk of using some of the same arguments used
by those who won't abandon SEU, I don't see the benefit.

I briefly tried i Projects, but quickly abandoned working with it. I
didn't see the benefit. It merely added extra work steps to my job. (I
really don't need to do extra work to get the basic work done.) Perhaps if
I spent time learning Git and figuring out how to integrate it with our
home-built change management and compile systems, it might be workable.
The problem is it needs a more direct integration with how I can compile
when I keep all my source in source physical file members today. If we had
control over the defaults for the CL build program, perhaps I could get it
to integrate better--e.g., specify the command that would be put into the
build CL for each member type, etc. Then if I could automatically review
the build program before I push the changes and compile, it might be
successful. I think the Build Specification build style might be helpful,
but I would have to get our SysAdmin to install and configure the i side
to make it productive.

It might also be useful if I worked disconnected. But at this point I
never do. The RDi help for i Projects specifically states, "The i Projects
perspective focuses on disconnected IBM® i development." I'm sure that's a
big part of my problem. So maybe I'm not the target of your question.

As far as using it to help integration with Git, I think if someone could
write a clear, concise description of what the benefit would be, I could
justify the effort to learn it. (Although a clear, concise set of
instructions on getting it set up and working would be helpful also.) I
get the impression that Git would more helpful if I needed to integrate
open source tools/projects. But most of those deal with things done in
PASE. We don't utilize a lot of PASE functions. I've integrated a few
helpful things where appropriate, but for those I see benefit. Right now,
the main problem is I have "real" work to do. By that I mean the work I
was hired to do. I do spend a fair amount of time writing utilities to
help the other programmers and staff in our company and department, but
that (at least hopefully) has benefit to my employer. At this point,
adding extra work to get my work done doesn't benefit me or my employer.
(Gads! Now I am sounding like those who prefer SEU over RDi.)

Michael Quigley
Computer Services
The Way International
www.TheWay.org

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.