esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darren Hague <dha...@fortybeans.com>
Subject Re: How about targetting a "release"?
Date Mon, 18 May 2009 22:06:04 GMT
It's not so much the documentation - with a bit of study, I can work out 
what the code is doing. Where I have trouble is refactoring it from 
there to where I want it to be (with particular reference here to 
getting the HTML out of the .scala files).  I think that better, more 
maintainable code will eliminate the need for much documentation.

Maybe we can tempt some of the other Lift guys in here? There is a great 
case for making ESME the poster child for Lift - but that means that the 
codebase must be readable, maintainable and well-commented. As I have 
said, given patterns to work from, I'm happy to do the spade work here. 
Yes, that makes me something of a script kiddie for now, but that (in 
combination with study) is how people learn.

Cheers,
Darren

Anne Kathrine Petteroe wrote:
> Darren,
>
> I have felt the missing documentation is a roadblock too, that was the 
> reason why I put Jira task #59 (Better documentation of our existing 
> Scala code) on my wishlist for a release.
> I've wanted to use ESME to learn Scala/Lift myself, but haven't found 
> our code being much help at all.
>
> @David: Is this something you could look at?
> Not sure how much time you have between now and June 30th?
>
> /Anne
>
> On 18. mai. 2009, at 21.17, Darren Hague wrote:
>
>> The outstanding HTML-out-of-Scala-code tickets would be good to 
>> address. I've looked at the Track one, but a couple of hours 
>> investigation led me nowhere. The HTML is just too embedded at the 
>> moment.  Unlike the Comet stuff, where the HTML was relatively easy 
>> to extract (because of the nature of Comet), I had no luck with the 
>> other stuff, short of wondering how to initialise a Scala XML node 
>> from an HTML file - for which I couldn't find any example code anywhere.
>>
>> Right now, and speaking as someone who's been dabbling in Scala & 
>> Lift for over a year, the ESME codebase is just too hard to work with 
>> in many of the areas I've investigated. Whatever it takes, and 
>> however long it takes, we need to get the codebase into a state where 
>> it is understandable and maintainable, and this is mostly beyond my 
>> skills at present.  I will buy the available Lift & Scala books as 
>> available to see if this helps, but in the short term my 
>> effectiveness is limited. I'm happy to do pattern-based work - if 
>> someone can show me an example of how something should be done, and 
>> wants a bunch more of it done, then I am happy to pitch in.
>>
>> Please note that I am not down on Scala & Lift themselves - I 
>> presented Scala to my team last week, and got some good feedback (to 
>> the degree that I may be allowed to include some Scala in the 
>> production code I'm working on) and I will be presenting Lift in the 
>> next few weeks.
>>
>> All the best,
>> Darren
>>
>> Vassil Dichev wrote:
>>> I've been thinking myself what it would take to release a finished
>>> version. A release would make it easier for others to try out ESME and
>>> a release schedule would motivate us to focus on short-term goals.
>>>
>>> I could add ESME-53 (Access pools), and the associated feature
>>> requests 54-57. Access pools are a personal itch, as their absence was
>>> the main reason a certain micromessaging solution has been rejected in
>>> a team I've been in. A lot of the server functionality for access
>>> pools is finished and the work left is mostly related to the UI.
>>>
>>> I wasn't fully aware that HTML cleanup from the scala files is
>>> stopping development of the current UI. If that's the case, I should
>>> probably put the access pools on hold and focus on this task, so
>>> others are not blocked by 60-63. Is this the case?
>>>
>>> As for a rewrite- anything more significant than the HTML/Scala
>>> refactoring is not at all realistic for a release schedule 1 1/2
>>> months from now. I would prefer that any rewrite with our current
>>> resources is incremental, if possible, otherwise it would mean ESME
>>> development is frozen for months. I have no desire to kill whatever
>>> inertia ESME has without any visible results at this time. It should
>>> be possible to focus on areas, which are not affected so much by the
>>> perceived inelegance of the code base. Remember- for the outside world
>>> it is important for ESME to deliver, otherwise it's easy to conclude
>>> ESME development is stalled.
>>>
>>> Vassil
>>>
>>
>


Mime
View raw message