On 10 Nov 2006, at 15:37, Bernard Devlin wrote:
Hi Dave,
I'm not sure if you intended this email to come to the list (some
stuff in it sounds oddly private), but since it is now in the
public domain, I'm going to reply to it. I'm not sure if I'm
getting all the mail that goes to the list, so apologies if I'm
posting out of context. Also, as it's a long reply, I'm going to
split it into sections (the list doesn't like messages above 15kb).
>>
There is definitely a problem with "silly" bugs and lack of a clear
way of finding answers to problems within the Rev environment - in
short it takes a long time (more than necessary) to become a RunRev
"expert".
<<
If a bug affects you, then yes it is annoying. But in 3 weeks of
intensive development, I came across 1 bug. The advice on how to
fix it was readily available by dropping in to chat with my chums
on ChatRev (indeed I felt very stupid for not thinking how to solve
it for myself). It wasn't a show stopper, but could well cause a
new user to doubt the power of Rev. As for your other remark about
how long it takes to become an expert - I have dabbled in Rev for
the past four years, committing myself instead to developing web
applications. Well, after 4 years I've come to the conclusion that
I have wasted far too much time trying to get reasonable UIs
working in those web applications (I was using what became the dojo
toolkit before AJAX was invented as a word/concept). I have
achieved far more in three weeks with Rev than I could have ever
achieved in 3 weeks of web development. In fact, I'm re-working an
entire client-side toolkit (that was previously written in Java by
a famous company with some of the best developers in the world),
and I'm adding features to it that they never had (such as
broadcasting change notifications to other users based on what data
they are currently viewing). One of the things that I have wanted
for a long time in Rev is integration with a VCS - so I've written
an application to convert Rev stacks to XML and back again, so that
they can be under version control. I'm a long way from being one
of the Rev experts to be found on this list, I would estimate that
over the past 4 years I've spent less than 5% of my programming
time using Rev, yet I would say that I'm able to achieve more in
Rev than I am (for example) in languages like Javascript or Java,
where I've spent considerably more time.
A lot of the problems I have encountered in RunRev haven't actually
been "Show Stoppers" as such because there is a workaround
available, however I decided early on that to be really efficient in
RunRev you need to develop your own framework (or use a 3rd party
system), if you do this right you can obtain the maximum code and
screen design re-use. The problems that I found were because I was
doing things that probably had not been tested and probably doing
things that 95% of RunRev Scripters/Programmers don't do!
I just don't know what you mean by "there is definitely a ... lack
of a clear way of finding answers to problems within the Rev
environment". The documentation is actually some of the best I
have seen (try using some Java libraries where all you get is an
API). There is this user group (where requests for help rarely go
unanswered) - I know official fora of some companies where 20% of
requests for help go unanswered.
For instance, do you know that the following statement:
put the cp1 of this stack into me
in a function in to the field script, will, under certain
circumstances fail and set the field to empty?
I wanted to be able to use "me" in this way so that the code was
completely context-free. I had maybe 10 windows to put together and I
wanted to make sure that this basic idea would work. I found that it
worked sometimes! So asked for help from the list and eventually
found out a work around. Now, from the documentation, tell me what
the workaround is! (Clue: I know of two ways). This was not a show
stopper in the sense that I couldn't just drop my idea and make my
code more context sensitive which would mean I'd have to do more work
and have more bugs, so I couldn't get on and develop my code until I
knew the answer, which after a few days discovered thanks to help
from the list. In this case the delay led to frustration, especially
when I knew the answer, which was (as are most answers!) simply to
implement!
All the Best
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
