On 4/19/2017 6:20 PM, Edmund Reinhardt wrote:
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.
Thank you Edmund!
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?
This is wicked long: if the reader is not interested in an excruciating
exposition of my experience, now is the time to press Ctrl-End and get
right to the bottom.
I myself am the only one in my group who has even tried i Projects, and
my usage is spotty at best. Since the earliest days, I never had a need
to develop offline. In fact, Ctrl-Shift-C (Compile) is so fast that I
never do Ctrl-Shift-V (Verify). My goal isn't 'verified' code, it's
tested and deployed executable code. Anything that takes me a step
further from that gets a sceptical side eye from me. Too many words
already to say that i Projects does not have clear and obvious utility
/to me/ when it comes to creating executable code in production.
That said, I figured there's no time like the present to give it a whirl
again. So these are my experience notes written contemporaneously. I
have a task I've been working on in RSE that involves some nasty SQL,
CPYFRM/TOIMPF, and FTP to get data to and fro between business partners.
There's a few CLPs and a few SQLRPGLEs, so it's small enough to try easily.
One note is in order. I practise TDD. ish. That means a quick cycle
of write a test, compile the test, write the code, compile the code,
test the code. I don't at all work in a batch: edit a hundred lines in
MBR1, edit a hundred lines in MBR2, edit a hundred lines in MBR3, push
the lot, compile the lot, test the lot. As a result, I don't use the
batch compilation CLP that i Projects generates at all.
Window > Open Perspective > i Projects
Alt-Shift-N > IBM i Project
My reaction: I like being able to choose a connexion. Not fond that I
have to choose one and only one library; my stuff is cross library, with
tables in one library and programs in another. I'll choose the program
library.
Now I have an empty project. I may be looking at this sideways, but
I've been working on this task for a week. I already have a connexion,
a filter, and a 'regular' RSE 'project' going. It'd be nice to have the
option to import the code from that connexion/filter into the project.
Associated with this, there's no option to import source; rather,
there's no menu/keyboardable option - I see I need to context click >
Import Remote Source... And having done that, it's drill down to the
Mohorovičić discontinuity to find the source members. Bleh. Worse, the
navigation tree can't 'see' my very ancient PF38 version of QCLSRC.
My reaction: That seems like a show-stopper, and especially frustrating
because I can see the darned member I want in the Remote Systems View
panel right below the i Projects View. I can't drag/drop anything from
the RSE to the i Project. No es bueno. Except, I forgot until just
this minute how I actually do it! Accurséd, frail memory! You wickedly
abandon me in my hour of need!
Open up the RSE View, context click the source member, Add to i Project.
I can say it in less words and I can do it in less words. It took mere
seconds to perform that operation on all the source members in my RSE
filter. I still wish for a context click on the connexion, but this'll
do. Oh, and a keyboardable option would be swell.
My reaction: Easy-peasy to go from RSE filter to i Project. Not so easy
to do that from inside the Project. But that's why I can have multiple
Views open simultaneously :-)
Now I have a project with source members in it. I don't have a change
management system in place, but I have Git [1], so I'll use that to
establish my baseline. Open Perspective > Other > Git, Alt-Shift-N,
filter Git, New Repo. The secret sauce here is to build the repo over
the i Project, in my case c:\buck\rdi9511_plugin\van\.git (van is my
project name). Ctrl-Shift-#, select all, and commit.
My reaction: This was painless and fits my idea of i Project in Utopia.
I run my CL and discover that I forgot to put a 'commit(*NONE)' on my
RUNSQL command. Time to edit! Muscle memory gotcha: Ctrl-Shift-C does
not compile. I need to push the changes from my PC to QCLSRC and then
do the compile. There's no keyboard shortcut to do the push, so I
context click, Remote Actions > Push selected. Then context click,
Remote Actions > Compile.
My reaction: Takes too long compared to Ctrl-Shift-C.
Because I try to use TDD, the extra mouse-only steps required to push
the changes and compile the changes adds an annoying amount of time to
my edit/compile/test cycle. The opposite of the TDD philosophy. That's
not a slam against i Projects: I think I'm trying to stuff it into a
corner it doesn't want to be in.
This particular task is the simplest possible one I could imagine. I am
working right in production (it's my script, it's still in development,
and no one else will be using/looking at it). If I had to work in a
test environment [2] and then promote to production I'd probably try to
use the 'compile clp' that i Projects generates.
Context click the project > Remote Actions > Generate COMPILE.CLLE
Well that brings back memories. Editing that, I see that everything is
hard coded. When I make my own 'batch compile' scripts, I put the
library in a variable that I can either pass in as a parameter, or
initialise on a DCL statement.
My reaction: Needs work. Fortunately, scan and replace makes it easy
enough to modify, but I think this concept is intended for a Really Big
Shop where three levels of management sign off on something before
development begins. I add too many 'whoops I forgot this one' members
on the fly to generate and fix up this COMPILE.CLLE more than once, so
it'd have to happen exactly once, at the very end of testing, after all
the layers have signed off and it's ready to promote.
There's another thing: Promotion. In RSE, I have a filter set up that
has only the source members I'm working with. I also have a User Action
I can use to promote from the test to the production library. None of
that functionality exists in i Projects. Assuming I associated the
Project with my test library, it seems kind of difficult within i
Projects to promote those members to production, where they'd ultimately
need to be compiled. It seems to me that the answer for my personal
situation is to open up an RSE connexion/filter over the test library
source members and use my regular User Commands to do the promote to
production, and then edit the COMPILE.CLLE to point to production and do
the mass compile.
My reaction: Needs work, but seems do-able as-is.
I think I'm ready to end this massive missive.
I am very thankful to have access to such a vocal group of customers that I
can get unfiltered, immediate feedback from.
I need to visit Canada and learn how to be this polite :-)
[1] What use is Git? I hear this a lot in my group. We don't use Git
as a group because I can't demonstrate the ROI, but I personally use it
to track changes, and commit/roll back changes across source members
exactly how I'd use SQL COMMIT to transactionalise DB changes made
across several tables.
Imagine I'm making a change to a CLP, an RPGLE, and a PRTF. It's a few
lines in each, and I make changes to each, test each, and when those
tests pass, I commit the group as one single commit action. Now Git
knows what changes went into TEST 1; what source members and what lines
of code in each source member. Then I go on to TEST 2, etc. At any
time I can roll back to an earlier 'set' or 'state' of source members.
In case I need to abandon one idea and start another.
[2] Every system has a test environment. A privileged few have a
segregated production environment in addition to that. :-)
midrange.com
