some karma remarks
Peter Gijsels
When working on my lesson, I had a look at some other lessons and I
took some notes.
In no particular order:
- In a number of lessons the path to help.png is set in lesson.css.
That is currently a problem for i18n.
- in index.html: <meta name="keywords"...>, why?
- in index.html: lots of html to make the lesson title, the same for
every lesson. We should maybe make a js function to do that.
- everybody is duplicating the way help works: move it to a central
place in our js library.
- idem linkBack, linkOle
- correct.ogg, incorrect.ogg duplicated across lots of lessons -> move
it to central location.
- audio playback (sometimes) stutters in Firefox 3.5.8 on the Mac.
Some comments on 6_English_alphabeticalOrder:
- 6_English_alphabeticalOrder_13_K/js/lesson.js, line 23,42: new
Array(...) can be simplified to [...].
- 6_English_alphabeticalOrder_13_K/js/lesson.js, line 47: use Karma.shuffle
- 6_English_alphabeticalOrder_13_K/js/lesson.js, line 68: css embedded
in js, maybe move to lesson.css?
- 6_English_alphabeticalOrder_13_K/js/lesson.js, line 91: 'tolerence'
should be tolerance
- 6_English_alphabeticalOrder_13_K/js/lesson.js: currentDragObject is
not needed. In drop, you can access it via ui (e.g.
$(ui.draggable[0])). dragstart can then be removed.
- 6_English_alphabeticalOrder_13_K/js/lesson.js:
$(".dropObjects").droppable({ tolerence: 'intersect' ,hoverClass:
'drophover' });
$('.dropObjects').bind('drop', function(event, ui) {...
can be replaced by:
$('.dropObjects').droppable({
tolerance:'intersect',
hoverClass:'drophover',
drop: function(event, ui) {
...}
})
Regards,
Peter
Bryan Berry
> Hi Bryan,
>
> When working on my lesson, I had a look at some other lessons and I
> took some notes.
> In no particular order:
> - In a number of lessons the path to help.png is set in lesson.css.
> That is currently a problem for i18n.
It definitely is. Adding images using CSS has a number of advantages
but is problematic for i18n. I believe it is generally considered a
best practice add your images using the css property background-image
property rather than using the <img> tag. It makes your html a lot
simpler but it complicates i18n
> - in index.html: <meta name="keywords"...>, why?
I think that is stuff is for search optimization. Felipe added it a
long time ago and I never deleted it.
> - in index.html: lots of html to make the lesson title, the same for
> every lesson. We should maybe make a js function to do that.
ui.kHeader.js fixes this issue
Somehow the up-to-date version of English_animalIdentification has
been wiped out in master
here is the up-to-date version:
http://git.olenepal.org/karma/karma/blobs/ce10928c84818fbf401b9ed8b1741b3514fbc50d/lessons/2_English_animalIdentification/
index.html
<div id="kHeader">
</div>
lesson.js
$('#kHeader').kHeader({'title': 'English Animal Identification',
lessonPlan: true, teachersNote: true});
kHeader also has a mechanism for handling the help file which u see in
the same lesson
ui.kFooter.js does something similar
> - everybody is duplicating the way help works: move it to a central
> place in our js library.
+1
> - idem linkBack, linkOle
? what does this mean
> - correct.ogg, incorrect.ogg duplicated across lots of lessons -> move
> it to central location.
Each lesson needs to be developed independently of all the others.
This eases the barrier to entry for anyone who wants to contribute and
I find that I almost always end up developing each lesson as a
stand-alone lesson. We need to make it easy to develop lessons
individually but then consolidate common files to save space at
build-time
> - audio playback (sometimes) stutters in Firefox 3.5.8 on the Mac.
Yeah, this is a problem w/ all versions of Firefox 3.5. Firefox 3.6
fixes the problem.
the lessons you refer to below were written by Vaibhaw.
Bryan Berry
On Thu, Mar 25, 2010 at 4:51 AM, Peter Gijsels <peter....@gmail.com> wrote:
> On Wed, Mar 24, 2010 at 12:39 PM, Bryan Berry <br...@olenepal.org> wrote:
>> On Wed, Mar 24, 2010 at 5:09 AM, Peter Gijsels <peter....@gmail.com> wrote:
>>> Hi Bryan,
>>>
>>> When working on my lesson, I had a look at some other lessons and I
>>> took some notes.
>>> In no particular order:
>>> - In a number of lessons the path to help.png is set in lesson.css.
>>> That is currently a problem for i18n.
>>
>> It definitely is. Adding images using CSS has a number of advantages
>> but is problematic for i18n. I believe it is generally considered a
>> best practice add your images using the css property background-image
>> property rather than using the <img> tag. It makes your html a lot
>> simpler but it complicates i18n
> Maybe the help text should also not be a png but simply text? That
> would be easier for the translators too.
+1
>>
>>> - in index.html: <meta name="keywords"...>, why?
>>
>> I think that is stuff is for search optimization. Felipe added it a
>> long time ago and I never deleted it.
> As far as I can tell from a quick googling, none of the major search
> engines take that into account any more. So maybe we can just drop it?
Agreed
>>
>>> - in index.html: lots of html to make the lesson title, the same for
>>> every lesson. We should maybe make a js function to do that.
>>
>> ui.kHeader.js fixes this issue
>>
>> Somehow the up-to-date version of English_animalIdentification has
>> been wiped out in master
>>
>> here is the up-to-date version:
>> http://git.olenepal.org/karma/karma/blobs/ce10928c84818fbf401b9ed8b1741b3514fbc50d/lessons/2_English_animalIdentification/
>>
>> index.html
>> <div id="kHeader">
>> </div>
>>
>> lesson.js
>> $('#kHeader').kHeader({'title': 'English Animal Identification',
>> lessonPlan: true, teachersNote: true});
>>
>> kHeader also has a mechanism for handling the help file which u see in
>> the same lesson
>>
>> ui.kFooter.js does something similar
>
> I'll have a look at these tomorrow when I have some time. But it looks
> promising.
>
>>
>>> - everybody is duplicating the way help works: move it to a central
>>> place in our js library.
>>
>> +1
>>
>>> - idem linkBack, linkOle
>> ? what does this mean
> In the header there is a link back and a link to the ole website. In a
> number of lessons there is duplicate code for these. So maybe they
> should also moved somewhere centrally.
>
>>> - correct.ogg, incorrect.ogg duplicated across lots of lessons -> move
>>> it to central location.
>>
>> Each lesson needs to be developed independently of all the others.
>> This eases the barrier to entry for anyone who wants to contribute and
>> I find that I almost always end up developing each lesson as a
>> stand-alone lesson. We need to make it easy to develop lessons
>> individually but then consolidate common files to save space at
>> build-time
>
> But you already need a number of central files (i.e. karma.js,
> global.css, etc.) to develop a lesson. And you are not forced to use
> these central files. If you want to develop a lesson as a stand-alone
> lesson, you can still put your
> files locally. Only now you have the option of reusing the central
> files. I don't see how this raises the barrier of entry.
OK, so what central directory should these sounds and images go in? We
need to make it easy to distinguish b/w sounds that need to be
centralized and those that don't
> Having most lessons reuse the same files will also make it easier to
> translate them: you can put one translation centrally instead of
> having to put the translations in each individual lesson.
>
> Do you have any documentation on how you build a release? I vaguely
> remember something about Jake, but in the latest git repository I
> don't find it anymore.
We were using Jake for a while but now using an extended version of
the Python script that we use for the flash stuff
Essentially the build script does this:
- moves all the *.js files from lesson_name/js - except for lesson.js
- to root_dir/js
- moves all the *.css files from lesson_name/css - except for
lesson.css - to root_dir/css
will try to find out from Abhishek, the buildmaster, which script he uses
Peter Gijsels
> pls make sure to cc karmajs, so others can read our conversation
>>>
>>> Each lesson needs to be developed independently of all the others.
>>> This eases the barrier to entry for anyone who wants to contribute and
>>> I find that I almost always end up developing each lesson as a
>>> stand-alone lesson. We need to make it easy to develop lessons
>>> individually but then consolidate common files to save space at
>>> build-time
>>
>> But you already need a number of central files (i.e. karma.js,
>> global.css, etc.) to develop a lesson. And you are not forced to use
>> these central files. If you want to develop a lesson as a stand-alone
>> lesson, you can still put your
>> files locally. Only now you have the option of reusing the central
>> files. I don't see how this raises the barrier of entry.
>
> OK, so what central directory should these sounds and images go in? We
> need to make it easy to distinguish b/w sounds that need to be
> centralized and those that don't
Maybe in the top-level assets directory karma/assets/audio ? I haven't
given it much thought, but it seems like a logical place.
Bryan Berry
>> need to make it easy to distinguish b/w sounds that need to be
>> centralized and those that don't
> Maybe in the top-level assets directory karma/assets/audio ? I haven't
> given it much thought, but it seems like a logical place.
We need to be able to split each lesson into its own individual git
repo, otherwise repo mgt will become a nightmare w/ n total lessons
and n committers. We are seeing this problem now
Each lesson needs to be developed from a template like the karma-lesson repo
http://git.sugarlabs.org/projects/karma-lesson/repos/mainline/trees/master
that can be bundled together w/ other lessons during a build process.
During this bundling process, we want to centralize common files but
protect files specific to each lesson. The easiest way to do this
would be to clearly delineate b/w files common to all lessons and
those specific to individual ones.
when each lesson is in its own repo there won't be a way to put files
at the top level karma/assets/audio
perhaps a karma/, template/, or common/ folder to hold css, images,
and audio common to all lessons? If you have correct.ogg that is
specific to your lesson, you don't put it in template/audio/
Peter Gijsels
>>> OK, so what central directory should these sounds and images go in? We
>>> need to make it easy to distinguish b/w sounds that need to be
>>> centralized and those that don't
>> Maybe in the top-level assets directory karma/assets/audio ? I haven't
>> given it much thought, but it seems like a logical place.
>
> We need to be able to split each lesson into its own individual git
> repo, otherwise repo mgt will become a nightmare w/ n total lessons
> and n committers. We are seeing this problem now
Git was specifically designed to deal with having a lot of committers
(I can imagine that the number of committers for the Linux kernel is
still a bit larger ;)). If people are working on different lessons
there should be no problem when merging, and if they are working on
the same lesson it will not make it easier if each lesson has its
separate repository.
I would prefer to have one big git repository instead of having one
repository per lesson. Can you elaborate on the kind of problems you
are seeing now?
What I could see is having one repository for the framework stuff and
a repository for all the lessons, which has the framework repository
as a git submodule (http://progit.org/book/ch6-6.html). But this is
more complex than having one big repository, so I would not start that
way. Once other groups start using karma for developing their own
lessons, that might be the correct time to do this split.
> Each lesson needs to be developed from a template like the karma-lesson repo
> http://git.sugarlabs.org/projects/karma-lesson/repos/mainline/trees/master
Is that repository up to date? The last update in that repository is
from february 17th. If we split each lesson in a separate repository,
with each having their copy of karma.js, we will constantly have this
problem: 'are you using the last version of karma.js?'
> that can be bundled together w/ other lessons during a build process.
What will you do if you try to bundle lessons which are using a
different version of karma.js? That seems like a nightmare to me.
>
> During this bundling process, we want to centralize common files but
> protect files specific to each lesson. The easiest way to do this
> would be to clearly delineate b/w files common to all lessons and
> those specific to individual ones.
I would go in the opposite direction. One big repo, with a way to
extract a bundle a subset of lessons during a build.
>
> when each lesson is in its own repo there won't be a way to put files
> at the top level karma/assets/audio
A reason to have one big repository.
Maybe I'm missing something important. If that's the case please
enlighten me. (I'm also interested because I moved everybody at work
over to one big common git repository for all our tools, so if there
are any hidden problems with this approach it would be nice to know
:))
Peter
Bryan Berry
> On Fri, Mar 26, 2010 at 1:45 AM, Bryan Berry <br...@olenepal.org> wrote:
>>>> OK, so what central directory should these sounds and images go in? We
>>>> need to make it easy to distinguish b/w sounds that need to be
>>>> centralized and those that don't
>>> Maybe in the top-level assets directory karma/assets/audio ? I haven't
>>> given it much thought, but it seems like a logical place.
>>
>> We need to be able to split each lesson into its own individual git
>> repo, otherwise repo mgt will become a nightmare w/ n total lessons
>> and n committers. We are seeing this problem now
>
> Git was specifically designed to deal with having a lot of committers
> (I can imagine that the number of committers for the Linux kernel is
> still a bit larger ;)). If people are working on different lessons
> there should be no problem when merging, and if they are working on
> the same lesson it will not make it easier if each lesson has its
> separate repository.
>
> I would prefer to have one big git repository instead of having one
> repository per lesson. Can you elaborate on the kind of problems you
> are seeing now?
Yes, the biggest problem is the repository is HUGE, around 220 MB. Git
was designed for large projects full of text files so git handles text
files very efficiently. Git does not handle binary data very
efficiently and that is one (only one) of the reasons our git repo is
so huge. We should expect Karma to keep growing rapidly, there isn't
much we can do about the binary problem. We can use git-filter-branch
to remove giant binary files that are no longer used but this changes
your entire history and thus is very problematic for a public repo.
The linux kernel is a very large project w/ lots of interdependencies
between modules.
Also, newbies want to start off w/ a very simple lesson, and not have
to download 220+ MB to get started
In the long-term and short-term we will always get requests to put
together a package of arbitrary Karma lessons. For example, all the
"stable" English lessons for Grade 6, weeks 1-4 , all "stable" Math
lessons for grade 6, weeks 1-4, so we will have to filter the lessons
arbitrarily on request. Making them modular will help in this regard.
"stable" in this context means tagged stable.
Another issue is versioning. Some lessons may be stable and others not
at any given moment. Having separate repos means we tag each repo w/
stable tag
see this link for more details
http://wiki.sugarlabs.org/go/Karma#Version_Control
> What I could see is having one repository for the framework stuff and
> a repository for all the lessons, which has the framework repository
> as a git submodule (http://progit.org/book/ch6-6.html). But this is
> more complex than having one big repository, so I would not start that
> way. Once other groups start using karma for developing their own
> lessons, that might be the correct time to do this split.
>
>> Each lesson needs to be developed from a template like the karma-lesson repo
>> http://git.sugarlabs.org/projects/karma-lesson/repos/mainline/trees/master
>
> Is that repository up to date? The last update in that repository is
> from february 17th. If we split each lesson in a separate repository,
> with each having their copy of karma.js, we will constantly have this
> problem: 'are you using the last version of karma.js?'
I agree it is a problem but we can get around it by putting a version
# in karma.js like karma-1.js . This is how we get around the problem
of using different versions of jQuery
>> that can be bundled together w/ other lessons during a build process.
> What will you do if you try to bundle lessons which are using a
> different version of karma.js? That seems like a nightmare to me.
>
>>
>> During this bundling process, we want to centralize common files but
>> protect files specific to each lesson. The easiest way to do this
>> would be to clearly delineate b/w files common to all lessons and
>> those specific to individual ones.
>
> I would go in the opposite direction. One big repo, with a way to
> extract a bundle a subset of lessons during a build.
Go for it. But in our experience working on 200+ flash lessons over
the last two years, the individual repos is easier to maintain and
work w/.
Bryan Berry
I would love to know what you guys think. Which do you prefer, one big
repo or lots of small repos?
Roshan Karki
both of you.
Bryan Berry
and individual repos for the flash lessons at hg.olenepal.org
Sooner rather than later, we should move to 1 src control system and
strategy for both flash and karma lessons. If we were to use 1 big for
both flash and Karma lessons, it would easily top 600 MB in size
NoiseEHC
> for the record we currently use 1 big repo for all the Karma lessons
> and individual repos for the flash lessons at hg.olenepal.org
>
What was the problem with Mercurial? It at least has tooling on Windows...
Peter Gijsels
I did some probing around in our repository. Remarks are below.
The repository being huge is a problem because of bandwidth or because
of storage? In my response below, I'll assume that it is because of
bandwith.
The 220 MB is the disk space that your repository is using locally.
Half of that space is used for your working copy and the other half is
in the .git directory which contains the complete (compressed)
history.
When you clone the repository you only transfer what is stored below
.git so roughly 110Mb. This transfer only happens once. Later pulls
are only proportional to the changes.
There are some big directories in our repository: the 'tools'
subdirectory alone takes 44 Mb. Maybe it doesn't need to be in the
same repository as the lessons.
I also imagine that we have been moving around lots of stuff and
accidently been checking in things that were not needed (and were
removed later, but are still in the git history), so I did the
following:
> cd tmp
> cp -r ~/projects/karma/nepal/ nepal
> cd nepal/
> rm -rf .git tools/
> git init
> git add .
> du -h .git
39M total
which basically start a git repository with a clean history and
without the 'tools' directory. The initial transfer is then only 39MB.
There are more savings to be had. If we look at some of the bigger files:
- there are 10MB of wav files spread out troughout the lessons. If you
convert this to .ogg you should save quite a bit (80%?).
- the alphabet and numeric puzzle are the two biggest lessons having
3.4MB of images. This is the double of what is needed: we have one big
image and then 16 pieces of that big image. I reworked that puzzle
game as an exercise, and do the cutting of the puzzle in pieces in
javascript, saving (at least) half the space.
- in the money identification we are using .png iso of .jpg for the
pictures of money.
> The linux kernel is a very large project w/ lots of interdependencies
> between modules.
>
> Also, newbies want to start off w/ a very simple lesson, and not have
> to download 220+ MB to get started
We can always provide a separate repository with a bare bones template
for newbies. It is however not because we provide that template for
newbies that our team needs to be using that approach.
> In the long-term and short-term we will always get requests to put
> together a package of arbitrary Karma lessons. For example, all the
> "stable" English lessons for Grade 6, weeks 1-4 , all "stable" Math
> lessons for grade 6, weeks 1-4, so we will have to filter the lessons
> arbitrarily on request. Making them modular will help in this regard.
> "stable" in this context means tagged stable.
> Another issue is versioning. Some lessons may be stable and others not
> at any given moment. Having separate repos means we tag each repo w/
> stable tag
You can use git branches to distinguish between stable lessons and
lessons in development. E.g. do all development on a development
branches (a branch per unstable lesson, until it is stable enough to
be merged to main).
I am not advocating to make the lessons any less modular. But I do
want a way to share content between lessons (e.g. correct.ogg,
incorrect.ogg). I also would like to avoid having lots of copies of
the common karma stuff (global.js, karma.js, *.css) in different
repositories. Even with consistent versioning numbers, I think this
would become unworkable.
What do you mean with 'go for it'?
Can you elaborate the kind of problems you experienced? I also have no
idea how these flash lessons were organized. Do they share any
content? Is there a common framework that they are using?
Regards,
Peter
Peter Gijsels
> for the record we currently use 1 big repo for all the Karma lessons
> and individual repos for the flash lessons at hg.olenepal.org
>
> Sooner rather than later, we should move to 1 src control system and
> strategy for both flash and karma lessons. If we were to use 1 big for
> both flash and Karma lessons, it would easily top 600 MB in size
Maybe we should keep the flash and karma lessons separate. Is there
anything than can be shared between the two? If not, I see no reason
to lump them together in the same repository. Especially because the
download size would balloon.
Peter
Bryan Berry
> The repository being huge is a problem because of bandwidth or because
> of storage? In my response below, I'll assume that it is because of
> bandwith.
bandwidth
> There are some big directories in our repository: the 'tools'
> subdirectory alone takes 44 Mb. Maybe it doesn't need to be in the
> same repository as the lessons.
I agree, it doesn't need to be in the same repo
> There are more savings to be had. If we look at some of the bigger files:
> - there are 10MB of wav files spread out troughout the lessons. If you
> convert this to .ogg you should save quite a bit (80%?).
But those .wav files still take up a lot of space in your .git/
> - the alphabet and numeric puzzle are the two biggest lessons having
> 3.4MB of images. This is the double of what is needed: we have one big
> image and then 16 pieces of that big image. I reworked that puzzle
> game as an exercise, and do the cutting of the puzzle in pieces in
> javascript, saving (at least) half the space.
> - in the money identification we are using .png iso of .jpg for the
> pictures of money.
New lessons usually start w/ overly large binary audio and image
files. In time devs learn to use smaller files but those huge initial
binary files live on in the git repo
> I am not advocating to make the lessons any less modular. But I do
> want a way to share content between lessons (e.g. correct.ogg,
> incorrect.ogg). I also would like to avoid having lots of copies of
> the common karma stuff (global.js, karma.js, *.css) in different
> repositories. Even with consistent versioning numbers, I think this
> would become unworkable.
I think the most productive way to move forward is for you, roshan,
and myself to have a meeting on IRC. Roshan maintains all the stuff
that goes into the E-Paath package and I intend for you take on the
day-to-day technical leadership of Karma when you get to Nepal. I will
participate in the discussion but leave the decisions up to you guys.
How about a meeting this coming Monday?
Bryan Berry
gitorious is a much nicer web interface than any hg offers, despite
that it was a major headache to set up.
Working together w/ devs in other countries, esp. Latin America is a
big goal for Karma. Using git will hopefully make this easier
> To unsubscribe from this group, send email to
> karmajs+unsubscribegooglegroups.com or reply to this email with the words
> "REMOVE ME" as the subject.
>
Peter Gijsels
Ok. I'll try to get on IRC 13.00 my time, 16.45 your time.
Peter
Roshan Karki
>
Bryan Berry
do we need aks to attend as well?
Roshan Karki
Ashok Basnet
I am not able to drag and drop the second part of lesson properly. Its not dropping at all.
About the Class 6 rolling the ball
Can anyone give me some idea about how to check the ball barriers. I have tried my level best but can't get any algorithm for it. So can anyone help out...
Looking forward for quick response as we don't have much time....
To unsubscribe from this group, send email to karmajs+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
--
Ashok Basnet
IOE, Pulchok Campus (I/I)
Microsoft Student Partner 2008-09
Office : Himalayan Techies, Sanepa, Lalitpur
Web Programmer
(http://himalayantechies.com)
More info : http://ashokbasnet.com.np
FaceBook : http://facebook.com/basnet.ashok
Peter Gijsels
About Class 6 action verb,
I am not able to drag and drop the second part of lesson properly. Its not dropping at all.
Hi Ashok,
Can you provide some more details?
The second part is where you have to form a question by drag&dropping words, correct?
The dropping will only work when the word and the line overlap at least one pixel. Is that the case when you are dropping? Maybe I should add something bigger as the drop target.
Regards,
Peter
Peter Gijsels
I put a new version of 6_English_actionVerb here:
http://dl.dropbox.com/u/3249723/6_English_actionVerb.tgz
Instead of having to drop the words exactly on the lines, there is now
a whole region above the line that gets highlighted and is an
acceptable place to drop.
Regards,
Peter