Re: Frustrations with Remedy Developer Studio 7.5

[Joe Martin D'Souza]

I’ve actually begun to like it better than the older AR Admin Tool. Initially I 
did feel the bite like some of you, as it seemed to be too ‘unfamiliar’ after 
having worked with a Admin tool like interface for years...

But eventually when you learn where some of the controls are and relearn how 
you do what you used to do in a slightly different way, it gets better..

I do agree though that some of those perspective settings etc are kind of 
confusing.. I haven’t quite figured it out yet either but then I haven’t RTFM, 
and preferred to learn it by groping around.. Maybe its time for a little bit 
of reading to learn the finer points for some of us including me..

Joe

PS: Pardon me if this message appears twice, but when I first sent it, I got a 
reject message saying that the total size of the message was over 1000 lines.. 
So I truncated some of it..


From: Pierson, Shawn 
Sent: Thursday, March 03, 2011 9:53 AM
Newsgroups: public.remedy.arsystem.general
To: arslist@ARSLIST.ORG 
Subject: Re: Frustrations with Remedy Developer Studio 7.5

At my employer, we are moving towards using Virtual Machines located on a 
server in our data center for our desktops.  I’m piloting that from more of a 
developer standpoint, and while I have my fair share of complaints about the 
performance of the VMs and other issues, I have noticed that some of the lag of 
reading and writing to the AR Server has diminished.  It’s odd, because in my 
virtual machine just using my web browser is really slow, but Developer Studio 
has gotten a lot faster.  I think an alternative that I would have explored if 
I wasn’t using the VM would be to load up Developer Studio on one of my servers 
and RDP to the server to develop there.  This doesn’t help those on Unix, but 
if you are in a Windows shop it may help.

 

Also, I use Eclipse for other types of development and find it easier than 
using Developer Studio, but I think it’s because Developer Studio is meant to 
retain some of the paradigm of the Admin Tool.  Does this mean that BMC 
eventually wants us all to be Java developers just to customize Remedy?  That’s 
the direction I speculate they may be going in, which also explains why they 
are trying to make their applications more configurable so you won’t have to 
develop as much.  Their new licensing structure also clearly puts AR System 
development in the back seat, and focuses almost exclusively on ITSM now.  If 
you convert from the “green” licensing model to the “blue” one, you need to be 
careful to make sure you don’t lose your licenses to run applications other 
than the OOtB ones.

 

Thanks,

 

Shawn Pierson 

Remedy Developer | Southern Union

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Shafqat Ayaz
Sent: Wednesday, March 02, 2011 9:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Frustrations with Remedy Developer Studio 7.5

 

** 

I am having the exact same problem with speed, every time i change something, 
not Save, just change, for example select a field and move it, it goes into a 
funk!
I think the people who wrote the code for Dev Studio have servers installed on 
their local machines and never bothered to do any testing over the network. I 
have found so many bugs and problems that it is unreal. if i wrote code like 
this i would get fired within a week.

 



Shafqat Ayaz



 

 




From: pritch 
To: arslist@ARSLIST.ORG
Sent: Tue, March 1, 2011 9:51:17 AM
Subject: Re: Frustrations with Remedy Developer Studio 7.5

I know y'all probably don't want to hear this, but I don't seem to have the
issues that you're mentioning - Dev Studio seems to function just fine. 
May not be like lightning, but it definitely doesn't take me 15, 30 or even
5 minutes to open update and save (even the more complex forms).

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"

Re: Frustrations with Remedy Developer Studio 7.5

[Pierson, Shawn]

At my employer, we are moving towards using Virtual Machines located on a 
server in our data center for our desktops.  I’m piloting that from more of a 
developer standpoint, and while I have my fair share of complaints about the 
performance of the VMs and other issues, I have noticed that some of the lag of 
reading and writing to the AR Server has diminished.  It’s odd, because in my 
virtual machine just using my web browser is really slow, but Developer Studio 
has gotten a lot faster.  I think an alternative that I would have explored if 
I wasn’t using the VM would be to load up Developer Studio on one of my servers 
and RDP to the server to develop there.  This doesn’t help those on Unix, but 
if you are in a Windows shop it may help.

Also, I use Eclipse for other types of development and find it easier than 
using Developer Studio, but I think it’s because Developer Studio is meant to 
retain some of the paradigm of the Admin Tool.  Does this mean that BMC 
eventually wants us all to be Java developers just to customize Remedy?  That’s 
the direction I speculate they may be going in, which also explains why they 
are trying to make their applications more configurable so you won’t have to 
develop as much.  Their new licensing structure also clearly puts AR System 
development in the back seat, and focuses almost exclusively on ITSM now.  If 
you convert from the “green” licensing model to the “blue” one, you need to be 
careful to make sure you don’t lose your licenses to run applications other 
than the OOtB ones.

Thanks,

Shawn Pierson
Remedy Developer | Southern Union

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Shafqat Ayaz
Sent: Wednesday, March 02, 2011 9:37 PM
To: arslist@ARSLIST.ORG
Subject: Re: Frustrations with Remedy Developer Studio 7.5

**
I am having the exact same problem with speed, every time i change something, 
not Save, just change, for example select a field and move it, it goes into a 
funk!
I think the people who wrote the code for Dev Studio have servers installed on 
their local machines and never bothered to do any testing over the network. I 
have found so many bugs and problems that it is unreal. if i wrote code like 
this i would get fired within a week.



Shafqat Ayaz




From: pritch 
To: arslist@ARSLIST.ORG
Sent: Tue, March 1, 2011 9:51:17 AM
Subject: Re: Frustrations with Remedy Developer Studio 7.5

I know y'all probably don't want to hear this, but I don't seem to have the
issues that you're mentioning - Dev Studio seems to function just fine.
May not be like lightning, but it definitely doesn't take me 15, 30 or even
5 minutes to open update and save (even the more complex forms).

On Tue, 1 Mar 2011 07:07:09 -0800, Robert Molenda
mailto:robert.mole...@gmail.com>>
wrote:
> The performance issues seem to never have been addressed with ANY of the
> incarnations of the "Admin Tool/Developer Studio" - this performance
issue
> has resulted in a "tooling requirement" for a Terminal Server available
> within the Data Center of the actual Remedy Server in order to perform
> routine work. WAN performance has decreased greatly. As you both are
> stating
> - a "quick fix is no longer quick!" - a 5 minute "open, update, save" can
> take 15 to 30 minutes easily.
>
> I've requested an enhancement many years ago about a "offline mode" where
> you extract a def-file, and run the tool against that - perfect for what
I
> call "airplane mode" where you want to look at code while traveling.
Should
> be easy one would think right..?? After all Panacea has had this offline
> comparison feature for YEARS...
>
> If I had the spare time (which no-one does, and slow tools make any hint
of
> that now impossible) - I would look to re-invent another tool - because
the
> API is sitting there for all of us to use... I know I've written extract
to
> def, update def, reimport def code before for mass updates!
>
> Competition brings out the "best of class" so to say - I wonder if some
of
> the partners like Panacea, RRR, etc might see this as a huge opportunity
to
> enhance their tools / products to suit the needs of the communities.
> Definitely would not be the FIRST TIME - that is for sure.
>
> I could just imagine - taking a Panacea extract of the system, get on the
> airplane, and start coding. Once I'm to the site a migration package is
> ready, if any objects I updated were also updated these are flagged so
> investigation could be made, else - click-whir-coffee-done... [Dang -
back
> to reality :( ]
>
> Opportunity knocks - lets see if someone can pickup the ball and run with
> it!!!
> Robert Molenda
>
> On Mon, Feb 28, 2011 at 3:17 PM, strauss 
> mailto:stra...@unt.edu>&g

Re: Frustrations with Remedy Developer Studio 7.5

[Shafqat Ayaz]

I am having the exact same problem with speed, every time i change something, 
not Save, just change, for example select a field and move it, it goes into a 
funk!
I think the people who wrote the code for Dev Studio have servers installed on 
their local machines and never bothered to do any testing over the network. I 
have found so many bugs and problems that it is unreal. if i wrote code like 
this i would get fired within a week.

 


Shafqat Ayaz








From: pritch 
To: arslist@ARSLIST.ORG
Sent: Tue, March 1, 2011 9:51:17 AM
Subject: Re: Frustrations with Remedy Developer Studio 7.5

I know y'all probably don't want to hear this, but I don't seem to have the
issues that you're mentioning - Dev Studio seems to function just fine. 
May not be like lightning, but it definitely doesn't take me 15, 30 or even
5 minutes to open update and save (even the more complex forms).

On Tue, 1 Mar 2011 07:07:09 -0800, Robert Molenda

wrote:
> The performance issues seem to never have been addressed with ANY of the
> incarnations of the "Admin Tool/Developer Studio" - this performance
issue
> has resulted in a "tooling requirement" for a Terminal Server available
> within the Data Center of the actual Remedy Server in order to perform
> routine work. WAN performance has decreased greatly. As you both are
> stating
> - a "quick fix is no longer quick!" - a 5 minute "open, update, save" can
> take 15 to 30 minutes easily.
> 
> I've requested an enhancement many years ago about a "offline mode" where
> you extract a def-file, and run the tool against that - perfect for what
I
> call "airplane mode" where you want to look at code while traveling.
Should
> be easy one would think right..?? After all Panacea has had this offline
> comparison feature for YEARS...
> 
> If I had the spare time (which no-one does, and slow tools make any hint
of
> that now impossible) - I would look to re-invent another tool - because
the
> API is sitting there for all of us to use... I know I've written extract
to
> def, update def, reimport def code before for mass updates!
> 
> Competition brings out the "best of class" so to say - I wonder if some
of
> the partners like Panacea, RRR, etc might see this as a huge opportunity
to
> enhance their tools / products to suit the needs of the communities.
> Definitely would not be the FIRST TIME - that is for sure.
> 
> I could just imagine - taking a Panacea extract of the system, get on the
> airplane, and start coding. Once I'm to the site a migration package is
> ready, if any objects I updated were also updated these are flagged so
> investigation could be made, else - click-whir-coffee-done... [Dang -
back
> to reality :( ]
> 
> Opportunity knocks - lets see if someone can pickup the ball and run with
> it!!!
> Robert Molenda
> 
> On Mon, Feb 28, 2011 at 3:17 PM, strauss  wrote:
> 
>> I’ve lost mine.  This so-called “application” is a HUGE piece of ^%$#%
on
>> the best day.
>>
>>
>>
>> Today I am fighting to clean up the dregs of the first Best Practices
>> Conversion Utility run, and I have to edit three things side by side;
the
>> customized active link prefixed with two * that was active, the interim
>> one
>> that was inactive with one * prefix, and the original, where the BPCU
>> combined the two inactive ones and left the active one hanging.  When I
>> open
>> all three they lay over one another by default.  There is no VIEW menu
>> where
>> you can select things like Cascade, Tile, Tile Vertically, or Tile
>> Horizontally like MOST decent windowing programs… NOTHING.  Support
>> explained that you had to grab the edges of the objects and drag them
>> manually into some sort of side by side array, a HUGE time-waster, and I
>> was
>> doing that earlier today, but now they refuse to be selected by the
>> mouse,
>> so I have to assume that it has gone into some obtuse mode where even
>> manual
>> manipulation of the editor environment is impossible.  Resetting the
>> Perspective has no effect.  Has anyone figured this one out?
>>
>>
>>
>> NO tool used for production work should be this crude or obtuse. 
Period.
>>
>>
>>
>> Christopher Strauss, Ph.D.
>> Call Tracking Administration Manager
>> University of North Texas Computing & IT Center
>> http://itsm.unt.edu/
>>
>> *From:* Action Request System discussion list(ARSList) [mailto:
>> arslist@ARSLIST.ORG] *On Behalf Of *Robert Halstead
>> *Sent:* Monday, February 14, 2011 4:44 PM
>> *To:* arslist@ARSLIST.ORG
>> *Su

Re: Frustrations with Remedy Developer Studio 7.5

[pritch]

I know y'all probably don't want to hear this, but I don't seem to have the
issues that you're mentioning - Dev Studio seems to function just fine. 
May not be like lightning, but it definitely doesn't take me 15, 30 or even
5 minutes to open update and save (even the more complex forms).

On Tue, 1 Mar 2011 07:07:09 -0800, Robert Molenda

wrote:
> The performance issues seem to never have been addressed with ANY of the
> incarnations of the "Admin Tool/Developer Studio" - this performance
issue
> has resulted in a "tooling requirement" for a Terminal Server available
> within the Data Center of the actual Remedy Server in order to perform
> routine work. WAN performance has decreased greatly. As you both are
> stating
> - a "quick fix is no longer quick!" - a 5 minute "open, update, save" can
> take 15 to 30 minutes easily.
> 
> I've requested an enhancement many years ago about a "offline mode" where
> you extract a def-file, and run the tool against that - perfect for what
I
> call "airplane mode" where you want to look at code while traveling.
Should
> be easy one would think right..?? After all Panacea has had this offline
> comparison feature for YEARS...
> 
> If I had the spare time (which no-one does, and slow tools make any hint
of
> that now impossible) - I would look to re-invent another tool - because
the
> API is sitting there for all of us to use... I know I've written extract
to
> def, update def, reimport def code before for mass updates!
> 
> Competition brings out the "best of class" so to say - I wonder if some
of
> the partners like Panacea, RRR, etc might see this as a huge opportunity
to
> enhance their tools / products to suit the needs of the communities.
> Definitely would not be the FIRST TIME - that is for sure.
> 
> I could just imagine - taking a Panacea extract of the system, get on the
> airplane, and start coding. Once I'm to the site a migration package is
> ready, if any objects I updated were also updated these are flagged so
> investigation could be made, else - click-whir-coffee-done... [Dang -
back
> to reality :( ]
> 
> Opportunity knocks - lets see if someone can pickup the ball and run with
> it!!!
> Robert Molenda
> 
> On Mon, Feb 28, 2011 at 3:17 PM, strauss  wrote:
> 
>> I’ve lost mine.  This so-called “application” is a HUGE piece of ^%$#%
on
>> the best day.
>>
>>
>>
>> Today I am fighting to clean up the dregs of the first Best Practices
>> Conversion Utility run, and I have to edit three things side by side;
the
>> customized active link prefixed with two * that was active, the interim
>> one
>> that was inactive with one * prefix, and the original, where the BPCU
>> combined the two inactive ones and left the active one hanging.  When I
>> open
>> all three they lay over one another by default.  There is no VIEW menu
>> where
>> you can select things like Cascade, Tile, Tile Vertically, or Tile
>> Horizontally like MOST decent windowing programs… NOTHING.  Support
>> explained that you had to grab the edges of the objects and drag them
>> manually into some sort of side by side array, a HUGE time-waster, and I
>> was
>> doing that earlier today, but now they refuse to be selected by the
>> mouse,
>> so I have to assume that it has gone into some obtuse mode where even
>> manual
>> manipulation of the editor environment is impossible.  Resetting the
>> Perspective has no effect.  Has anyone figured this one out?
>>
>>
>>
>> NO tool used for production work should be this crude or obtuse. 
Period.
>>
>>
>>
>> Christopher Strauss, Ph.D.
>> Call Tracking Administration Manager
>> University of North Texas Computing & IT Center
>> http://itsm.unt.edu/
>>
>> *From:* Action Request System discussion list(ARSList) [mailto:
>> arslist@ARSLIST.ORG] *On Behalf Of *Robert Halstead
>> *Sent:* Monday, February 14, 2011 4:44 PM
>> *To:* arslist@ARSLIST.ORG
>> *Subject:* Frustrations with Remedy Developer Studio 7.5
>>
>>
>>
>> ** Forgive me as this is more of a rant.
>>
>>
>>
>> My patience for Remedy Developer Studio 7.5 is growing thin.  I find
that
>> performing the most insignificant tasks become a test in patience as the
>> tool communicates to server for every single action.
>>
>>
>>
>> Selecting a field on a form, talk to the server to get properties.
>>
>> Selecting multiple fields, talk to the server to get all properties.
>>
>> Select a field in a web service definition...
>>
>&

Re: Frustrations with Remedy Developer Studio 7.5

[Robert Molenda]

The performance issues seem to never have been addressed with ANY of the
incarnations of the "Admin Tool/Developer Studio" - this performance issue
has resulted in a "tooling requirement" for a Terminal Server available
within the Data Center of the actual Remedy Server in order to perform
routine work. WAN performance has decreased greatly. As you both are stating
- a "quick fix is no longer quick!" - a 5 minute "open, update, save" can
take 15 to 30 minutes easily.

I've requested an enhancement many years ago about a "offline mode" where
you extract a def-file, and run the tool against that - perfect for what I
call "airplane mode" where you want to look at code while traveling. Should
be easy one would think right..?? After all Panacea has had this offline
comparison feature for YEARS...

If I had the spare time (which no-one does, and slow tools make any hint of
that now impossible) - I would look to re-invent another tool - because the
API is sitting there for all of us to use... I know I've written extract to
def, update def, reimport def code before for mass updates!

Competition brings out the "best of class" so to say - I wonder if some of
the partners like Panacea, RRR, etc might see this as a huge opportunity to
enhance their tools / products to suit the needs of the communities.
Definitely would not be the FIRST TIME - that is for sure.

I could just imagine - taking a Panacea extract of the system, get on the
airplane, and start coding. Once I'm to the site a migration package is
ready, if any objects I updated were also updated these are flagged so
investigation could be made, else - click-whir-coffee-done... [Dang - back
to reality :( ]

Opportunity knocks - lets see if someone can pickup the ball and run with
it!!!
Robert Molenda

On Mon, Feb 28, 2011 at 3:17 PM, strauss  wrote:

> I’ve lost mine.  This so-called “application” is a HUGE piece of ^%$#% on
> the best day.
>
>
>
> Today I am fighting to clean up the dregs of the first Best Practices
> Conversion Utility run, and I have to edit three things side by side; the
> customized active link prefixed with two * that was active, the interim one
> that was inactive with one * prefix, and the original, where the BPCU
> combined the two inactive ones and left the active one hanging.  When I open
> all three they lay over one another by default.  There is no VIEW menu where
> you can select things like Cascade, Tile, Tile Vertically, or Tile
> Horizontally like MOST decent windowing programs… NOTHING.  Support
> explained that you had to grab the edges of the objects and drag them
> manually into some sort of side by side array, a HUGE time-waster, and I was
> doing that earlier today, but now they refuse to be selected by the mouse,
> so I have to assume that it has gone into some obtuse mode where even manual
> manipulation of the editor environment is impossible.  Resetting the
> Perspective has no effect.  Has anyone figured this one out?
>
>
>
> NO tool used for production work should be this crude or obtuse.  Period.
>
>
>
> Christopher Strauss, Ph.D.
> Call Tracking Administration Manager
> University of North Texas Computing & IT Center
> http://itsm.unt.edu/
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Robert Halstead
> *Sent:* Monday, February 14, 2011 4:44 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Frustrations with Remedy Developer Studio 7.5
>
>
>
> ** Forgive me as this is more of a rant.
>
>
>
> My patience for Remedy Developer Studio 7.5 is growing thin.  I find that
> performing the most insignificant tasks become a test in patience as the
> tool communicates to server for every single action.
>
>
>
> Selecting a field on a form, talk to the server to get properties.
>
> Selecting multiple fields, talk to the server to get all properties.
>
> Select a field in a web service definition...
>
>
>
> The latter will take quite a bit of time if you have a lot of fields on a
> form.
>
>
>
> I'm getting very frustrated with the performance of the Developer Studio..
>  I wish that the tool cached the objects from the database like the Migrator
> does and only updates when needed or when the developer forces the refresh.
>  Even have a periodic refresh would be nice..
>
>
>
> I wish that the tool wasn't so chatty back to the server.  It doesn't make
> sense that when object reservation is enabled, that the tool would need to
> go to the server for each field (like it would have changed since I have the
> form reserved?).
>
>
>
> Right now I'm pulling my hair out trying to modify a web service operation
> we have on one of our forms 

Re: Frustrations with Remedy Developer Studio 7.5

[strauss]

I’ve lost mine.  This so-called “application” is a HUGE piece of ^%$#% on the 
best day.

Today I am fighting to clean up the dregs of the first Best Practices 
Conversion Utility run, and I have to edit three things side by side; the 
customized active link prefixed with two * that was active, the interim one 
that was inactive with one * prefix, and the original, where the BPCU combined 
the two inactive ones and left the active one hanging.  When I open all three 
they lay over one another by default.  There is no VIEW menu where you can 
select things like Cascade, Tile, Tile Vertically, or Tile Horizontally like 
MOST decent windowing programs… NOTHING.  Support explained that you had to 
grab the edges of the objects and drag them manually into some sort of side by 
side array, a HUGE time-waster, and I was doing that earlier today, but now 
they refuse to be selected by the mouse, so I have to assume that it has gone 
into some obtuse mode where even manual manipulation of the editor environment 
is impossible.  Resetting the Perspective has no effect.  Has anyone figured 
this one out?

NO tool used for production work should be this crude or obtuse.  Period.

Christopher Strauss, Ph.D.
Call Tracking Administration Manager
University of North Texas Computing & IT Center
http://itsm.unt.edu/
From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Robert Halstead
Sent: Monday, February 14, 2011 4:44 PM
To: arslist@ARSLIST.ORG
Subject: Frustrations with Remedy Developer Studio 7.5

** Forgive me as this is more of a rant.

My patience for Remedy Developer Studio 7.5 is growing thin.  I find that 
performing the most insignificant tasks become a test in patience as the tool 
communicates to server for every single action.

Selecting a field on a form, talk to the server to get properties.
Selecting multiple fields, talk to the server to get all properties.
Select a field in a web service definition...

The latter will take quite a bit of time if you have a lot of fields on a form.

I'm getting very frustrated with the performance of the Developer Studio..  I 
wish that the tool cached the objects from the database like the Migrator does 
and only updates when needed or when the developer forces the refresh.  Even 
have a periodic refresh would be nice..

I wish that the tool wasn't so chatty back to the server.  It doesn't make 
sense that when object reservation is enabled, that the tool would need to go 
to the server for each field (like it would have changed since I have the form 
reserved?).

Right now I'm pulling my hair out trying to modify a web service operation we 
have on one of our forms that has 100+ fields.  Every time I remove / add a 
output mapping field, the developer studio does some mass server communication 
that takes about 30 seconds.  To do what exactly, I'm not sure...  If I have 
the web service object reserved, why would it need to go to the server for 
changes or whatever?  I haven't even saved the object yet... why is it talking 
to the server??

Why can't it just load the entire web service object and the form it references 
into a cache so that the "user experience" is fast and snappy after the initial 
load?  Then when I save the web service, perform the due diligence to ensure 
the mappings are correct.

I have used the knowledge base to look for "enhancements" and tricks when using 
the developer studio, but alas it seems no one else suffers from this issue or 
no one has encountered it / reported it.

It would be nice if BMC provided configuration settings that we could pass to 
the developer studio to configure how we want the tool to act and when we want 
the tool to communicate to the database or put more options in the preferences 
to configure the performance of the developer studio.

Perhaps something greater than just adjusting the memory that java uses...
Perhaps there could be a white paper on database optimizations that would help 
the developer studio perform better.

It would also be nice if while we are waiting for a form or other object to 
load, that a progress bar is displayed or something that tells us what the tool 
is doing. Most of my time spent in the developer studio is the "white screen" 
as the tool becomes unresponsive during save's or object retrievals from the 
server..   As a developer, I want to know what the tool is doing so that when I 
complain to BMC that the performance is slow, I have a point of reference.  If 
I know generally what is going on, maybe I can optimize the database so that 
the operation is quicker?  Who knows!

Whats frustrating is that after 1 revision and 7 patches later, I would expect 
the developer studio to have all the bugs and performance issues ironed out and 
be fast and snappy...  Nope.

How do BMC's Remedy developers program in this?  Don't they get frustrated with 
the NullPointerErr

Re: Frustrations with Remedy Developer Studio 7.5

[Jason Miller]

Thanks for the info!  I have never combed through a log of DS activity
(probably because I don't notice any problems 8-).

Is it possible to RDP a Windows machine that is inside of the network?  When
I am not in the office the only way to work is remoting the PC at my desk in
the office (although I realize that is not a option for everybody).

Like LJ, I gave up long ago on trying to use the Admin Tool over VPN
(although I did use DS over my
RAPconnection
the other day and it worked pretty well).  I stopped doing it not
only because of the delays but also so whatever operation I was doing would
not be interrupted by a dropped connection.  Too many times the connection
would drop while I was saving an object or doing an import.  With RDP you
just connect back up and continue where you left off.

Let us know how it goes.

Jason

On Mon, Feb 14, 2011 at 4:32 PM, Robert Halstead wrote:

> ** Thank you for the replies guys.  A RDP is not possible as our server is
> on a unix machine.  I admit that I am going through a VPN connection over
> cable most of the time, but even when I am in the office the dev studio is
> unchanged in performance.
>
> Thanks for the feedback Jason.  I will download and try DS 7.6.03 and see
> if my experiences improve with that version *fingers crossed*.
>
> Our remedy servers are on a different subnet than our work stations (as I
> would assume most companies are) and don't expect that to be so much the
> problem as it's all inside our network.  I do realize i'm on a VPN
> connection however and do expect some delay, but what I have been
> experiencing seems to be excessive.
>
> I have tailed the arsql log during my sessions using the 7.5 developer and
> can say that many sql commands are sent to the database per operation in the
> dev studio, which I expect for saves and refreshes, but again with only
> displaying field properties or adding an operation to an active link, why is
> it talking to the server? I would think it would have more cached about the
> server on initial connect.
>
> I have thought about going through the arsql logs, and one at a time, make
> sure the proper indexes are being used or if we can add additional indexes
> to the SQL commands as a last resort.
>
> Thanks again for the feedback guys, you have relieved a very frustrating
> developer.
>
>
> On Mon, Feb 14, 2011 at 3:28 PM, Jason Miller wrote:
>
>> ** Bob,
>>
>>
>> Have you tried DS 7.6.xx?  Many of the DS operations were move from the
>> Admin thread to a List thread starting with DS 7.6.03.  DS now only takes an
>> Admin thread if it needs it (typically saving).  DS 7.6.03 has a number of
>> improvements.  I talked to the DS lead quite a while at WWRUG10 (and WWRUG09
>> for that matter) and verified that it is safe to use a 7.6.03 DS with an AR
>> 7.5 system.  If DS sees it is connected to a AR 7.5 server it will not give
>> you the options that are not valid for AR 7.5.  There are some features that
>> are DS specific such as the way threads are used as well as a cool new "Open
>> In Browser" function that are not dependent on the AR Server version.
>>
>> Regarding caching I have noticed there seems to be some caching done.  If
>> I try to open a object that is reserved by somebody else I need to refresh
>> the list of objects (after asking them to release it) before DS shows it is
>> available and I can reserve it.
>>
>> While I have noticed some occasional delays and crashes (not nearly as
>> often with 7.6.03) our system is by no means painful do dev work on.  The
>> Admin Tool also had it issues with delays when loading objects too.
>> Admittedly I am about 300 feet from our the servers.
>>
>> One thing I have noticed, and I am not sure if this is related to
>> chattiness with the server or DS is just better aware of the changes you are
>> making and objects you already have open, is that I can modify one object
>> (say add a field to a form) and a workflow object (AL/Filter) that I already
>> have open is aware of the new field without having to close the workflow
>> object.  I find this to be a nice improvement over the Admin Tool.
>>
>> I understand completely a dev tool that is constantly making you wait is
>> extremely frustrating and makes it just about impossible to work with.  I am
>> just wondering if the problem is really DS or something else about the
>> environment?
>>
>> Have you run a sniffer between your machine and the server?  Do you know
>> that the issue is a chattiness issue?  If you cannot run a sniffer a server
>> side API log should also show chatty behavior.
>>
>> Are you on the same network as your Remedy server, within fairly close
>> physical proximity?  Or are you working over global network and/or over a
>> VPN?
>>
>> Jason
>>
>>
>> On Mon, Feb 14, 2011 at 2:44 PM, Robert Halstead wrote:
>>
>>> ** Forgive me as this is more of a rant.
>>>
>>> My patience for Remedy Developer Studio 7.5 is growing thin.  I

Re: Frustrations with Remedy Developer Studio 7.5

[remedy]

Quoting you:
"I have tailed the arsql log during my sessions using the 7.5 developer and
can say that many sql commands are sent to the database per operation in the
dev studio, which I expect for saves and refreshes, but again with only
displaying field properties or adding an operation to an active link, why is
it talking to the server? I would think it would have more cached about the
server on initial connect."


I wanted to make sure that you knew that all definitions are stored in the
database, not just ticket data. That means all field properties, workflow
properties, forms, everything. That is why it makes so many calls to the
DB. Everytime you want to look at a field, it needs to get the data from
the DB. Now imagin anything with a qualification such as a table field, it
needs to pull data for multiple objects, forms and their fields, and then
decode an internal string into a readable string. Always lots of DB
activity.



Les Ganton


> Thank you for the replies guys.  A RDP is not possible as our server is on
> a
> unix machine.  I admit that I am going through a VPN connection over cable
> most of the time, but even when I am in the office the dev studio is
> unchanged in performance.
>
> Thanks for the feedback Jason.  I will download and try DS 7.6.03 and see
> if
> my experiences improve with that version *fingers crossed*.
>
> Our remedy servers are on a different subnet than our work stations (as I
> would assume most companies are) and don't expect that to be so much the
> problem as it's all inside our network.  I do realize i'm on a VPN
> connection however and do expect some delay, but what I have been
> experiencing seems to be excessive.
>
> I have tailed the arsql log during my sessions using the 7.5 developer and
> can say that many sql commands are sent to the database per operation in
> the
> dev studio, which I expect for saves and refreshes, but again with only
> displaying field properties or adding an operation to an active link, why
> is
> it talking to the server? I would think it would have more cached about
> the
> server on initial connect.
>
> I have thought about going through the arsql logs, and one at a time, make
> sure the proper indexes are being used or if we can add additional indexes
> to the SQL commands as a last resort.
>
> Thanks again for the feedback guys, you have relieved a very frustrating
> developer.
>
>
> On Mon, Feb 14, 2011 at 3:28 PM, Jason Miller
> wrote:
>
>> ** Bob,
>>
>> Have you tried DS 7.6.xx?  Many of the DS operations were move from the
>> Admin thread to a List thread starting with DS 7.6.03.  DS now only
>> takes an
>> Admin thread if it needs it (typically saving).  DS 7.6.03 has a number
>> of
>> improvements.  I talked to the DS lead quite a while at WWRUG10 (and
>> WWRUG09
>> for that matter) and verified that it is safe to use a 7.6.03 DS with an
>> AR
>> 7.5 system.  If DS sees it is connected to a AR 7.5 server it will not
>> give
>> you the options that are not valid for AR 7.5.  There are some features
>> that
>> are DS specific such as the way threads are used as well as a cool new
>> "Open
>> In Browser" function that are not dependent on the AR Server version.
>>
>> Regarding caching I have noticed there seems to be some caching done.
>> If I
>> try to open a object that is reserved by somebody else I need to refresh
>> the
>> list of objects (after asking them to release it) before DS shows it is
>> available and I can reserve it.
>>
>> While I have noticed some occasional delays and crashes (not nearly as
>> often with 7.6.03) our system is by no means painful do dev work on.
>> The
>> Admin Tool also had it issues with delays when loading objects too.
>> Admittedly I am about 300 feet from our the servers.
>>
>> One thing I have noticed, and I am not sure if this is related to
>> chattiness with the server or DS is just better aware of the changes you
>> are
>> making and objects you already have open, is that I can modify one
>> object
>> (say add a field to a form) and a workflow object (AL/Filter) that I
>> already
>> have open is aware of the new field without having to close the workflow
>> object.  I find this to be a nice improvement over the Admin Tool.
>>
>> I understand completely a dev tool that is constantly making you wait is
>> extremely frustrating and makes it just about impossible to work with.
>> I am
>> just wondering if the problem is really DS or something else about the
>> environment?
>>
>> Have you run a sniffer between your machine and the server?  Do you know
>> that the issue is a chattiness issue?  If you cannot run a sniffer a
>> server
>> side API log should also show chatty behavior.
>>
>> Are you on the same network as your Remedy server, within fairly close
>> physical proximity?  Or are you working over global network and/or over
>> a
>> VPN?
>>
>> Jason
>>
>>
>> On Mon, Feb 14, 2011 at 2:44 PM, Robert Halstead
>> wrote:
>>
>>> ** Forgive me as this is more of a rant.
>>>
>>> My patience

Re: Frustrations with Remedy Developer Studio 7.5

[Robert Halstead]

Thank you for the replies guys.  A RDP is not possible as our server is on a
unix machine.  I admit that I am going through a VPN connection over cable
most of the time, but even when I am in the office the dev studio is
unchanged in performance.

Thanks for the feedback Jason.  I will download and try DS 7.6.03 and see if
my experiences improve with that version *fingers crossed*.

Our remedy servers are on a different subnet than our work stations (as I
would assume most companies are) and don't expect that to be so much the
problem as it's all inside our network.  I do realize i'm on a VPN
connection however and do expect some delay, but what I have been
experiencing seems to be excessive.

I have tailed the arsql log during my sessions using the 7.5 developer and
can say that many sql commands are sent to the database per operation in the
dev studio, which I expect for saves and refreshes, but again with only
displaying field properties or adding an operation to an active link, why is
it talking to the server? I would think it would have more cached about the
server on initial connect.

I have thought about going through the arsql logs, and one at a time, make
sure the proper indexes are being used or if we can add additional indexes
to the SQL commands as a last resort.

Thanks again for the feedback guys, you have relieved a very frustrating
developer.


On Mon, Feb 14, 2011 at 3:28 PM, Jason Miller wrote:

> ** Bob,
>
> Have you tried DS 7.6.xx?  Many of the DS operations were move from the
> Admin thread to a List thread starting with DS 7.6.03.  DS now only takes an
> Admin thread if it needs it (typically saving).  DS 7.6.03 has a number of
> improvements.  I talked to the DS lead quite a while at WWRUG10 (and WWRUG09
> for that matter) and verified that it is safe to use a 7.6.03 DS with an AR
> 7.5 system.  If DS sees it is connected to a AR 7.5 server it will not give
> you the options that are not valid for AR 7.5.  There are some features that
> are DS specific such as the way threads are used as well as a cool new "Open
> In Browser" function that are not dependent on the AR Server version.
>
> Regarding caching I have noticed there seems to be some caching done.  If I
> try to open a object that is reserved by somebody else I need to refresh the
> list of objects (after asking them to release it) before DS shows it is
> available and I can reserve it.
>
> While I have noticed some occasional delays and crashes (not nearly as
> often with 7.6.03) our system is by no means painful do dev work on.  The
> Admin Tool also had it issues with delays when loading objects too.
> Admittedly I am about 300 feet from our the servers.
>
> One thing I have noticed, and I am not sure if this is related to
> chattiness with the server or DS is just better aware of the changes you are
> making and objects you already have open, is that I can modify one object
> (say add a field to a form) and a workflow object (AL/Filter) that I already
> have open is aware of the new field without having to close the workflow
> object.  I find this to be a nice improvement over the Admin Tool.
>
> I understand completely a dev tool that is constantly making you wait is
> extremely frustrating and makes it just about impossible to work with.  I am
> just wondering if the problem is really DS or something else about the
> environment?
>
> Have you run a sniffer between your machine and the server?  Do you know
> that the issue is a chattiness issue?  If you cannot run a sniffer a server
> side API log should also show chatty behavior.
>
> Are you on the same network as your Remedy server, within fairly close
> physical proximity?  Or are you working over global network and/or over a
> VPN?
>
> Jason
>
>
> On Mon, Feb 14, 2011 at 2:44 PM, Robert Halstead wrote:
>
>> ** Forgive me as this is more of a rant.
>>
>> My patience for Remedy Developer Studio 7.5 is growing thin.  I find that
>> performing the most insignificant tasks become a test in patience as the
>> tool communicates to server for every single action.
>>
>> Selecting a field on a form, talk to the server to get properties.
>> Selecting multiple fields, talk to the server to get all properties.
>> Select a field in a web service definition...
>>
>> The latter will take quite a bit of time if you have a lot of fields on a
>> form.
>>
>> I'm getting very frustrated with the performance of the Developer Studio..
>>  I wish that the tool cached the objects from the database like the Migrator
>> does and only updates when needed or when the developer forces the refresh.
>>  Even have a periodic refresh would be nice..
>>
>> I wish that the tool wasn't so chatty back to the server.  It doesn't make
>> sense that when object reservation is enabled, that the tool would need to
>> go to the server for each field (like it would have changed since I have the
>> form reserved?).
>>
>> Right now I'm pulling my hair out trying to modify a web service operation
>> we have on on

Re: Frustrations with Remedy Developer Studio 7.5

[Jason Miller]

Bob,

Have you tried DS 7.6.xx?  Many of the DS operations were move from the
Admin thread to a List thread starting with DS 7.6.03.  DS now only takes an
Admin thread if it needs it (typically saving).  DS 7.6.03 has a number of
improvements.  I talked to the DS lead quite a while at WWRUG10 (and WWRUG09
for that matter) and verified that it is safe to use a 7.6.03 DS with an AR
7.5 system.  If DS sees it is connected to a AR 7.5 server it will not give
you the options that are not valid for AR 7.5.  There are some features that
are DS specific such as the way threads are used as well as a cool new "Open
In Browser" function that are not dependent on the AR Server version.

Regarding caching I have noticed there seems to be some caching done.  If I
try to open a object that is reserved by somebody else I need to refresh the
list of objects (after asking them to release it) before DS shows it is
available and I can reserve it.

While I have noticed some occasional delays and crashes (not nearly as often
with 7.6.03) our system is by no means painful do dev work on.  The Admin
Tool also had it issues with delays when loading objects too.  Admittedly I
am about 300 feet from our the servers.

One thing I have noticed, and I am not sure if this is related to chattiness
with the server or DS is just better aware of the changes you are making and
objects you already have open, is that I can modify one object (say add a
field to a form) and a workflow object (AL/Filter) that I already have open
is aware of the new field without having to close the workflow object.  I
find this to be a nice improvement over the Admin Tool.

I understand completely a dev tool that is constantly making you wait is
extremely frustrating and makes it just about impossible to work with.  I am
just wondering if the problem is really DS or something else about the
environment?

Have you run a sniffer between your machine and the server?  Do you know
that the issue is a chattiness issue?  If you cannot run a sniffer a server
side API log should also show chatty behavior.

Are you on the same network as your Remedy server, within fairly close
physical proximity?  Or are you working over global network and/or over a
VPN?

Jason


On Mon, Feb 14, 2011 at 2:44 PM, Robert Halstead wrote:

> ** Forgive me as this is more of a rant.
>
> My patience for Remedy Developer Studio 7.5 is growing thin.  I find that
> performing the most insignificant tasks become a test in patience as the
> tool communicates to server for every single action.
>
> Selecting a field on a form, talk to the server to get properties.
> Selecting multiple fields, talk to the server to get all properties.
> Select a field in a web service definition...
>
> The latter will take quite a bit of time if you have a lot of fields on a
> form.
>
> I'm getting very frustrated with the performance of the Developer Studio..
>  I wish that the tool cached the objects from the database like the Migrator
> does and only updates when needed or when the developer forces the refresh.
>  Even have a periodic refresh would be nice..
>
> I wish that the tool wasn't so chatty back to the server.  It doesn't make
> sense that when object reservation is enabled, that the tool would need to
> go to the server for each field (like it would have changed since I have the
> form reserved?).
>
> Right now I'm pulling my hair out trying to modify a web service operation
> we have on one of our forms that has 100+ fields.  Every time I remove / add
> a output mapping field, the developer studio does some mass server
> communication that takes about 30 seconds.  To do what exactly, I'm not
> sure...  If I have the web service object reserved, why would it need to go
> to the server for changes or whatever?  I haven't even saved the object
> yet... why is it talking to the server??
>
> Why can't it just load the entire web service object and the form it
> references into a cache so that the "user experience" is fast and snappy
> after the initial load?  Then when I save the web service, perform the due
> diligence to ensure the mappings are correct.
>
> I have used the knowledge base to look for "enhancements" and tricks when
> using the developer studio, but alas it seems no one else suffers from this
> issue or no one has encountered it / reported it.
>
> It would be nice if BMC provided configuration settings that we could pass
> to the developer studio to configure how we want the tool to act and when we
> want the tool to communicate to the database or put more options in the
> preferences to configure the performance of the developer studio.
>
> Perhaps something greater than just adjusting the memory that java uses...
> Perhaps there could be a white paper on database optimizations that would
> help the developer studio perform better.
>
> It would also be nice if while we are waiting for a form or other object to
> load, that a progress bar is displayed or something that tells us what the
> tool i

Re: Frustrations with Remedy Developer Studio 7.5

[LJ LongWing]

Bob,

I LONG AGO started using the Admin/Dev Studio from a RDP session into my 
server….it just made sense at the time I started doing it, and still does.  My 
Dev servers are a relatively slow network link away from my VPN location, so 
any/all interaction with them other than the user tool is excruciating….I don’t 
know if that’s an option for you….but when doing anything other than ‘light 
work’, I do it through RDP on the server itself J

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Robert Halstead
Sent: Monday, February 14, 2011 3:44 PM
To: arslist@ARSLIST.ORG
Subject: Frustrations with Remedy Developer Studio 7.5

 

** Forgive me as this is more of a rant.

 

My patience for Remedy Developer Studio 7.5 is growing thin.  I find that 
performing the most insignificant tasks become a test in patience as the tool 
communicates to server for every single action.  

 

Selecting a field on a form, talk to the server to get properties.  

Selecting multiple fields, talk to the server to get all properties.  

Select a field in a web service definition... 

 

The latter will take quite a bit of time if you have a lot of fields on a form.

 

I'm getting very frustrated with the performance of the Developer Studio..  I 
wish that the tool cached the objects from the database like the Migrator does 
and only updates when needed or when the developer forces the refresh.  Even 
have a periodic refresh would be nice..

 

I wish that the tool wasn't so chatty back to the server.  It doesn't make 
sense that when object reservation is enabled, that the tool would need to go 
to the server for each field (like it would have changed since I have the form 
reserved?).

 

Right now I'm pulling my hair out trying to modify a web service operation we 
have on one of our forms that has 100+ fields.  Every time I remove / add a 
output mapping field, the developer studio does some mass server communication 
that takes about 30 seconds.  To do what exactly, I'm not sure...  If I have 
the web service object reserved, why would it need to go to the server for 
changes or whatever?  I haven't even saved the object yet... why is it talking 
to the server??

 

Why can't it just load the entire web service object and the form it references 
into a cache so that the "user experience" is fast and snappy after the initial 
load?  Then when I save the web service, perform the due diligence to ensure 
the mappings are correct.

 

I have used the knowledge base to look for "enhancements" and tricks when using 
the developer studio, but alas it seems no one else suffers from this issue or 
no one has encountered it / reported it.

 

It would be nice if BMC provided configuration settings that we could pass to 
the developer studio to configure how we want the tool to act and when we want 
the tool to communicate to the database or put more options in the preferences 
to configure the performance of the developer studio.

 

Perhaps something greater than just adjusting the memory that java uses...

Perhaps there could be a white paper on database optimizations that would help 
the developer studio perform better.

 

It would also be nice if while we are waiting for a form or other object to 
load, that a progress bar is displayed or something that tells us what the tool 
is doing. Most of my time spent in the developer studio is the "white screen" 
as the tool becomes unresponsive during save's or object retrievals from the 
server..   As a developer, I want to know what the tool is doing so that when I 
complain to BMC that the performance is slow, I have a point of reference.  If 
I know generally what is going on, maybe I can optimize the database so that 
the operation is quicker?  Who knows!

 

Whats frustrating is that after 1 revision and 7 patches later, I would expect 
the developer studio to have all the bugs and performance issues ironed out and 
be fast and snappy...  Nope.

 

How do BMC's Remedy developers program in this?  Don't they get frustrated with 
the NullPointerErrors and slow responsiveness? I'm guessing that they just 
install a remedy server on their local box to avoid the performance issue of 
the network.

 

I think the development studio is a giant step up from the old Remedy 
Administrator that we have all used in the past.  But now that the tool is main 
stream, there needs to be some serious work done to make the tool more 
responsive and optimized when connecting over the network.

 

Again, sorry for the rant, I just needed to vent.


-- 
"A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on 
only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed."

Bob Halstead

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

Re: Frustrations with Remedy Developer Studio 7.5

[Robert Halstead]

Thanks for replying Tommy.  Yea I know about the dev cache mode and we have
it enabled on our dev server.  Even with the dev cache mode turned on, I
just wish the developer studio didn't talk to the server so much and had a
cache of it's own.  IMO, it should only talk to the server when I'm opening
the object and saving the object.. With the exception of modifying table
fields I guess ;)

On Mon, Feb 14, 2011 at 2:56 PM, Tommy Morris
wrote:

> One thing to make sure of is that Developer Cache Mode is turned on. Our
> app server crashed every time a developer would try to do anything in Dev
> Tool without dev cache mode on. And since we cannot put the server in Dev
> Cache mode during Production Hours I have to do after hours “code changes”
> to change the time on a notification escalation.
>
>
>
> *From:* Action Request System discussion list(ARSList) [mailto:
> arslist@ARSLIST.ORG] *On Behalf Of *Robert Halstead
> *Sent:* Monday, February 14, 2011 4:44 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Frustrations with Remedy Developer Studio 7.5
>
>
>
> ** Forgive me as this is more of a rant.
>
>
>
> My patience for Remedy Developer Studio 7.5 is growing thin.  I find that
> performing the most insignificant tasks become a test in patience as the
> tool communicates to server for every single action.
>
>
>
> Selecting a field on a form, talk to the server to get properties.
>
> Selecting multiple fields, talk to the server to get all properties.
>
> Select a field in a web service definition...
>
>
>
> The latter will take quite a bit of time if you have a lot of fields on a
> form.
>
>
>
> I'm getting very frustrated with the performance of the Developer Studio..
>  I wish that the tool cached the objects from the database like the Migrator
> does and only updates when needed or when the developer forces the refresh.
>  Even have a periodic refresh would be nice..
>
>
>
> I wish that the tool wasn't so chatty back to the server.  It doesn't make
> sense that when object reservation is enabled, that the tool would need to
> go to the server for each field (like it would have changed since I have the
> form reserved?).
>
>
>
> Right now I'm pulling my hair out trying to modify a web service operation
> we have on one of our forms that has 100+ fields.  Every time I remove / add
> a output mapping field, the developer studio does some mass server
> communication that takes about 30 seconds.  To do what exactly, I'm not
> sure...  If I have the web service object reserved, why would it need to go
> to the server for changes or whatever?  I haven't even saved the object
> yet... why is it talking to the server??
>
>
>
> Why can't it just load the entire web service object and the form it
> references into a cache so that the "user experience" is fast and snappy
> after the initial load?  Then when I save the web service, perform the due
> diligence to ensure the mappings are correct.
>
>
>
> I have used the knowledge base to look for "enhancements" and tricks when
> using the developer studio, but alas it seems no one else suffers from this
> issue or no one has encountered it / reported it.
>
>
>
> It would be nice if BMC provided configuration settings that we could pass
> to the developer studio to configure how we want the tool to act and when we
> want the tool to communicate to the database or put more options in the
> preferences to configure the performance of the developer studio.
>
>
>
> Perhaps something greater than just adjusting the memory that java uses...
>
> Perhaps there could be a white paper on database optimizations that would
> help the developer studio perform better.
>
>
>
> It would also be nice if while we are waiting for a form or other object to
> load, that a progress bar is displayed or something that tells us what the
> tool is doing. Most of my time spent in the developer studio is the "white
> screen" as the tool becomes unresponsive during save's or object retrievals
> from the server..   As a developer, I want to know what the tool is doing so
> that when I complain to BMC that the performance is slow, I have a point of
> reference.  If I know generally what is going on, maybe I can optimize the
> database so that the operation is quicker?  Who knows!
>
>
>
> Whats frustrating is that after 1 revision and 7 patches later, I would
> expect the developer studio to have all the bugs and performance issues
> ironed out and be fast and snappy...  Nope.
>
>
>
> How do BMC's Remedy developers program in this?  Don't they get frustrated
> with the NullPointerErrors and s

Re: Frustrations with Remedy Developer Studio 7.5

[Tommy Morris]

One thing to make sure of is that Developer Cache Mode is turned on. Our app 
server crashed every time a developer would try to do anything in Dev Tool 
without dev cache mode on. And since we cannot put the server in Dev Cache mode 
during Production Hours I have to do after hours “code changes” to change the 
time on a notification escalation.

 

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Robert Halstead
Sent: Monday, February 14, 2011 4:44 PM
To: arslist@ARSLIST.ORG
Subject: Frustrations with Remedy Developer Studio 7.5

 

** Forgive me as this is more of a rant.

 

My patience for Remedy Developer Studio 7.5 is growing thin.  I find that 
performing the most insignificant tasks become a test in patience as the tool 
communicates to server for every single action.  

 

Selecting a field on a form, talk to the server to get properties.  

Selecting multiple fields, talk to the server to get all properties.  

Select a field in a web service definition... 

 

The latter will take quite a bit of time if you have a lot of fields on a form.

 

I'm getting very frustrated with the performance of the Developer Studio..  I 
wish that the tool cached the objects from the database like the Migrator does 
and only updates when needed or when the developer forces the refresh.  Even 
have a periodic refresh would be nice..

 

I wish that the tool wasn't so chatty back to the server.  It doesn't make 
sense that when object reservation is enabled, that the tool would need to go 
to the server for each field (like it would have changed since I have the form 
reserved?).

 

Right now I'm pulling my hair out trying to modify a web service operation we 
have on one of our forms that has 100+ fields.  Every time I remove / add a 
output mapping field, the developer studio does some mass server communication 
that takes about 30 seconds.  To do what exactly, I'm not sure...  If I have 
the web service object reserved, why would it need to go to the server for 
changes or whatever?  I haven't even saved the object yet... why is it talking 
to the server??

 

Why can't it just load the entire web service object and the form it references 
into a cache so that the "user experience" is fast and snappy after the initial 
load?  Then when I save the web service, perform the due diligence to ensure 
the mappings are correct.

 

I have used the knowledge base to look for "enhancements" and tricks when using 
the developer studio, but alas it seems no one else suffers from this issue or 
no one has encountered it / reported it.

 

It would be nice if BMC provided configuration settings that we could pass to 
the developer studio to configure how we want the tool to act and when we want 
the tool to communicate to the database or put more options in the preferences 
to configure the performance of the developer studio.

 

Perhaps something greater than just adjusting the memory that java uses...

Perhaps there could be a white paper on database optimizations that would help 
the developer studio perform better.

 

It would also be nice if while we are waiting for a form or other object to 
load, that a progress bar is displayed or something that tells us what the tool 
is doing. Most of my time spent in the developer studio is the "white screen" 
as the tool becomes unresponsive during save's or object retrievals from the 
server..   As a developer, I want to know what the tool is doing so that when I 
complain to BMC that the performance is slow, I have a point of reference.  If 
I know generally what is going on, maybe I can optimize the database so that 
the operation is quicker?  Who knows!

 

Whats frustrating is that after 1 revision and 7 patches later, I would expect 
the developer studio to have all the bugs and performance issues ironed out and 
be fast and snappy...  Nope.

 

How do BMC's Remedy developers program in this?  Don't they get frustrated with 
the NullPointerErrors and slow responsiveness? I'm guessing that they just 
install a remedy server on their local box to avoid the performance issue of 
the network.

 

I think the development studio is a giant step up from the old Remedy 
Administrator that we have all used in the past.  But now that the tool is main 
stream, there needs to be some serious work done to make the tool more 
responsive and optimized when connecting over the network.

 

Again, sorry for the rant, I just needed to vent.


-- 
"A fool acts, regardless; knowing well that he is wrong. The ignoramus acts on 
only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed."

Bob Halstead

_attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ 

Frustrations with Remedy Developer Studio 7.5

[Robert Halstead]

Forgive me as this is more of a rant.

My patience for Remedy Developer Studio 7.5 is growing thin.  I find that
performing the most insignificant tasks become a test in patience as the
tool communicates to server for every single action.

Selecting a field on a form, talk to the server to get properties.
Selecting multiple fields, talk to the server to get all properties.
Select a field in a web service definition...

The latter will take quite a bit of time if you have a lot of fields on a
form.

I'm getting very frustrated with the performance of the Developer Studio..
 I wish that the tool cached the objects from the database like the Migrator
does and only updates when needed or when the developer forces the refresh.
 Even have a periodic refresh would be nice..

I wish that the tool wasn't so chatty back to the server.  It doesn't make
sense that when object reservation is enabled, that the tool would need to
go to the server for each field (like it would have changed since I have the
form reserved?).

Right now I'm pulling my hair out trying to modify a web service operation
we have on one of our forms that has 100+ fields.  Every time I remove / add
a output mapping field, the developer studio does some mass server
communication that takes about 30 seconds.  To do what exactly, I'm not
sure...  If I have the web service object reserved, why would it need to go
to the server for changes or whatever?  I haven't even saved the object
yet... why is it talking to the server??

Why can't it just load the entire web service object and the form it
references into a cache so that the "user experience" is fast and snappy
after the initial load?  Then when I save the web service, perform the due
diligence to ensure the mappings are correct.

I have used the knowledge base to look for "enhancements" and tricks when
using the developer studio, but alas it seems no one else suffers from this
issue or no one has encountered it / reported it.

It would be nice if BMC provided configuration settings that we could pass
to the developer studio to configure how we want the tool to act and when we
want the tool to communicate to the database or put more options in the
preferences to configure the performance of the developer studio.

Perhaps something greater than just adjusting the memory that java uses...
Perhaps there could be a white paper on database optimizations that would
help the developer studio perform better.

It would also be nice if while we are waiting for a form or other object to
load, that a progress bar is displayed or something that tells us what the
tool is doing. Most of my time spent in the developer studio is the "white
screen" as the tool becomes unresponsive during save's or object retrievals
from the server..   As a developer, I want to know what the tool is doing so
that when I complain to BMC that the performance is slow, I have a point of
reference.  If I know generally what is going on, maybe I can optimize the
database so that the operation is quicker?  Who knows!

Whats frustrating is that after 1 revision and 7 patches later, I would
expect the developer studio to have all the bugs and performance issues
ironed out and be fast and snappy...  Nope.

How do BMC's Remedy developers program in this?  Don't they get frustrated
with the NullPointerErrors and slow responsiveness? I'm guessing that they
just install a remedy server on their local box to avoid the performance
issue of the network.

I think the development studio is a giant step up from the old Remedy
Administrator that we have all used in the past.  But now that the tool is
main stream, there needs to be some serious work done to make the tool more
responsive and optimized when connecting over the network.

Again, sorry for the rant, I just needed to vent.

-- 
"A fool acts, regardless; knowing well that he is wrong. The ignoramus acts
on only what he knows, but all that he knows.
The ignoramus may be saved, but the fool knows that he is doomed."

Bob Halstead

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"