19 Jun
2013
19 Jun
'13
7:47 p.m.
2013/6/19 Buddhiprabha Erabadda <buddhiprabha31481(a)gmail.com>
Hi All,
I had been going through the code during past days and I have put down
below what I have been doing.
To ensure I have configured the development environment correctly, I tried
to build the three REST modules. At first I started building on my Windows
machine, but it failed. As I understood this was due to file size
limitations on Windows. Is that a common reason? Is it not possible to
build from source on Windows? Because of the issues I set up a virtual
machine with Ubuntu installed and I could successfully build the three REST
modules on that machine.
As the first task, I started with enabling support for more Android
versions. The current application is supported only for Android 3.0 and
above, but there is a great number of users who have lower versions running
on their devices. Therefore I thought the application should ideally work
with Android 2.1 and above. The issue is visible as the list items of the
application do not load when the application starts on lower versions of
Android. I spent time finding a workaround and carrying out changes in the
code, but they did not work out. The application uses App Framework [1] as
the JavaScript library and when I carry out few changes in the library, the
behaviour changes by listing the items on the list but the href's of the
items are disabled. The changes do not make the application work properly,
but it leads me to think whether the library does not function with lower
versions of Android. Is there an issue like this with versions below
Android 3.0 when working with App Framework?
Hard to tell. We are not really AppFramework specialists at XWiki, as the
mobile app is the only projects that uses it.
I'll take a look. Can you detail a bit the issue in JIRA and what you found
?
Ludovic
I wanted to make the application available on all widely used Android
versions as my first task, but the issue I mentioned persists. Can someone
please tell me whether it is a known issue with Android lower versions
working with App Framework?
As the next task I will work on implementing child browser view for Android
as Ludovic advised me previously.
I will send public mails with my progress so that all can review, not only
the mentor. :) I will first design the approach on the public mailing list
and create a design page.
Thank you.
[1] http://app-framework-software.intel.com/
---------- Forwarded message ----------
From: Ludovic Dubost <ludovic(a)xwiki.com>
Date: Tue, Jun 18, 2013 at 8:53 PM
Subject: Re: [xwiki-devs] [GSOC] First coding period started
To: XWiki Developers <devs(a)xwiki.org>
Good point for you Buddhi. Can you please summarize what you've been doing
lately.
And not more emails directly to me :)
Ludovic
2013/6/18 Ecaterina Moraru (Valica) <valicac(a)gmail.com>
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Hello Buddhiprabha,
Yesterday we entered the 'Coding' period of the Google Summer of Code
2013.
There are some things that need to be mentioned
about GSOC that could
help
any student contributing to XWiki:
= Mentorship =
We prefer open mentorship. While your assigned mentor is the one
officially
in charge with your guidance, almost all
interaction should be done 'in
the
open' as much as possible, on the IRC channel
or on the mailing list. You
should choose the communication medium according to the importance of the
matters to be discussed: naturally, the less important issues are to be
discussed on IRC, while the design decisions, important progress
announcements and testing/feedback requests go on the list. This way, the
community is informed on the evolution of your project, and other
developers can come up any time with useful ideas and suggestions.
Moreover, if your mentor is hit by a bus (the bus factor [1]), another
developer can take his place with little effort.
= Communication =
Sitting alone in your room, working secretly on your project is
definitely
a bad approach. However, please keep in mind that
too much communication
can also be harmful, as it distracts the others from their own work. You
need to be able to communicate just right:
- provide meaningful information about your progress,
- ask the community's opinion on non-trivial design or implementation
decisions
- avoid wasting a lot of time on a problem, when a more experienced
developer (or a student that fought the same problem) could quickly
provide
you an answer; however, do try to find the answer
yourself at first.
Wrong: "Where do I start? What do I do now? And how do I do that? Is this
good? It doesn't work, help me!"
Right: "Since a couple of hours ago I get a strange exception when
building
my project, and googling for a solution
doesn't seem to help. Looking at
the error, I think that there's a wrong setting for the assembly plugin,
but nothing I tried works. Can someone please take a look?"
Subscribe to the devs list (if you didn't do this already), and start
monitoring the discussions. It is also recommended to subscribe to the
users list, but not mandatory. The notifications list is a little too
high
volume and technical for the moment, but it is a
great knowledge source.
= Development process =
The project's lifecycle is NOT design -> implementation -> testing ->
documentation. [2]
We invite you to adopt a test driven development [3][4][5] approach and
to
experience agile development [6]. After the first
coding week, you must
have some code that works. It won't do much, of course, but it will be
the
seed of your project. Every functionality will be
validated by tests. The
code must be properly tested and commented at the time of the writing
(don't think you'll do that afterwards, because in most cases you won't).
We encourage you to do __at least__ weekly commits (ideally, if you are
well organized, you should be able to commit code that works daily, so
try
to aim at daily commits). This way, the code can
be
properly reviewed, and any problems can be detected before they grow into
something too difficult to fix. One big code blob committed at the end,
no
matter how good it may seem, is a failure at
several levels.
= Documenting your work/progress =
We expect students to document their work/progress in 2 ways:
1) Design page in the Design [7] space on xwiki.org
GSoC students should create a Design page where they document technical
aspects of the feature they are working on: architecture, use cases,
problems, various solutions with pros and cons, etc. This page should be
written as an XWiki community member and not a GSoC student (there is the
progress report for that), ensuring that the page will remain relevant
even
after the GSoC period ends.
2) 'Progress' section of the GSoC project [8]
This is the place where the students set their goals (milestones and
deliverables) and where they report their advance towards completing
them.
More details and examples are available at
[9][10][11].
= Conclusions =
Since we are already in the coding period, there are some things that
need
to be done:
1. Answer this mail :)
2. Create a Design page [7] regarding your project
3. Start idling on the IRC channel
4. Start chatting on the mailing list and on IRC about your project and
other aspects of XWiki that you don't yet understand
5. Get your hands dirty by diving into the code and fixing Jira issue
6. Talk about your project
We want to know what you don`t understand about XWiki, what issue you are
planning to undertake, what you want to start with, etc.
It helps you more to start saying incorrect things and fixing them early
instead of staying quiet and making a big bad choice towards the end.
And a last thing, please remember that one-to-one conversations with your
mentor are not encouraged and are actually harmful to the success of your
project. Talk to the community, ask for help early and life will be
sweeter.
According to the timeline [12], you have 6 weeks of work available until
the mid-term evaluation. Please make sure you have the conditions for
success [13] in mind throughout all of the 12 total weeks of GSoC coding.
Happy coding!
Ecaterina on behalf of XWiki Mentors
[1] http://en.wikipedia.org/wiki/Bus_factor
[2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
[3] http://en.wikipedia.org/wiki/Test-driven_development
[4] http://www.amazon.com/dp/0321146530/
[5] http://www.amazon.com/dp/0201485672/
[6] http://www.amazon.com/dp/0596527675/
[7] http://dev.xwiki.org/xwiki/bin/view/Design/
[8]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HSelectedPro…
[9]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr…
[10]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/SOLRsearchcomponent
[11]
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Responsiveskinbasedo…
http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HConditionsf…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
*Buddhiprabha Erabadda*
*Department of Computer Science and Engineering*
*University of Moratuwa*
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs