Re: Google Summer of Code proposal for Javascript Frontend

On Sun, Apr 1, 2012 at 6:58 AM, Dustin J. Mitchell <dustin <at> v.igoro.us> wrote:
> On Wed, Mar 28, 2012 at 1:01 PM, Naveen Kumar
<naveen.iitm90@...> wrote:
>> This is first draft of my proposal. Please give your feedback
>
> As I mentioned in IRC, this looks good.
>
>> 1. Javasciprt frameworks:
>> Possible options:
>>         1. jQuery
>>         2. Dojo
>>         3. YUI
>
> This is a good preliminary list.  I suspect that part of the summer
> will be building "test" implementations in a few frameworks so that
> you can make a judgement based on experience.
>
>> 2. User interface design:
>> This is the best time to implement a better looking design. I am not
>> very good with web design. I am going to need help with that part. My
>> idea of implementation is, first implement a general template which
>> will be used in all the pages then implement rest of the features on
>> it.
>
> As Tom said, I think that the UI design is a separate task from the
> implementation of basic usability.  We don't have anyone within the
> project who has a great strength here, either, so this may be
> something to leave unfinished, in the sense that the UI at the end of
> the summer is perhaps a bit clunky, but all of the support is there
> for someone else to improve it.
>
> I suspect that building that support will be most of a summers' work,
> in fact -- and for the project such work is actually *far* more
> important than getting any particular pages implemented at all.  If
> you finished the summer with an aweomse buildbot.js library written
> that integrates tightly with one or more external JS libraries like
> jQuery and provides easy, reliable access to the Buildbot API -- but
> only actually implemented the build page with it -- I would count that
> a resounding success.  On the other hand, if you produce working
> JavaScript code for a half-dozen user-visible pages, but each is
> implemented in an ad-hoc fashion and not particularly flexible or
> maintainable, that would be somewhat disappointing.
>
>> As I understand JsonStatusResource class serves the /json requests,
>> and is used in WebStatus class in baseweb.py. Hence it is synchronous.
>> Any python coding work will be mostly in status_json.py unless I have
>> to interact with databases. I am not aware of code outside of this
>> module.
>
> And you could coordinate with other developers on the project to make
> the needed changes.
>
> As a note, depending on the timeline, I may have a significant chunk
> of the *new* API finished, and it would be great to begin your
> JavaScript work against that.  In particular, it will include support
> for dynamically updating pages as state changes.
>
>> Schedule:
>> Google Summer of Code program is spanned over 12 weeks(excluding
>> community bonding period).
>> 2 weeks: familizing with code, deciding upon things(javascript
>> framework, features to implement).
>> 5 -6 weeks: implement existing features i.e. builders, buildslaves,
>> build details, waterfall. As directed in other thread of devel list
>> tests also will be written along with the code.
>> 2-3 weeks: Survey for extra features and implement them.
>> 2 weeks: Wrap up. Merge missing code(if any).
>
> One thing to keep in mind is that there is potentially a long time
> between finishing some code and seeing it merged into the upstream
> codebase.  I'd like to see a bit more detail here about what can
> happen in overlapping chunks: after you've submitted a patch for one
> thing and are waiting for review, what will you work on?  I also like
> to see concrete artifacts described in a schedule: as of week three I
> will produce ___.  This gives the you and your mentor measurable goals
> to aim for, and helps the rest of the development community know what
> to expect over the course of the summer.
>
> Perhaps more importantly, I think that your project will include a
> good bit of experimentation.  For example, an effective technique for
> selecting the best JS library for the purpose might be to implement a
> "fake" buildmaster in Django (since you're comfortable with it), and
> then build a simple JS frontend on top of it using each of the
> possible libraries.  Then you, and the development community as a
> whole, could get some real-world experience with the libraries and
> make an informed decision.  Even though most of that code would not
> end up in Buildbot, this would be an excellent contribution to the
> project.
>
> Even once that is done, you may do several iterations of writing a
> low-level library, then building a page on top of it, only to find
> that the library could be better designed.
>
>> I have fairly good experience in python. I know twisted basics. I
>> mostly work on django for web development. I used javascipt/jQuery in
>> web development projects. I have little experience with UI design.
>> Though I follow some opensource projects never really contributed to
>> any of them. This is the first time I am working for an open source
>> project. We use git in our college for versioning. I am comfortable
>> with it.
>
> Welcome!  I think that this is a strong application, and demonstrates
> that you've done your homework.  I look forward to seeing the final
> proposal! (of course, another draft is welcome too)
>
Thanks for your feed back. I updated my proposal as per your suggestions.

Link http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/wakeupsid/1
> Dustin

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev