Posts Tagged ‘CDOT’

Good Sunday evening! I am coming to the end of the semester and to my final release in OSD. I would say, that it was and it is a great class that opens new horizons to students and possible opportunities to their future. I am so happy that I was and I am involved with such great companies as CDOT and Mozilla.

Previous week was the hardest one for me in terms of time, all the assignment presentations and assignment deadlines were there. Also I finished reading a great Sci-Fi book “Calculating God” last Sunday.

Lets get back to my work throughout the last week.
I was working on implementation GA events to goggles – bug968291, I was continuing this bug from the week before the last week. I became a little bit harder than I excepted, but it even better. It turned out that, from this bug we started 3 more new bugs, , which I took already:

Basically, all 3 bugs related to the same problem/feature: to update goggles to use requireJS whenever its possible. Why 3 bug? Because, in this way it’s easier to stay on track.
I started to work on bug995318 (my commit with progress) and made progress on that already. The main idea of the requireJS is to optimize in browser use and it makes app more efficient and work faster.
I would provide short guide on how it works.
The tree of directories:

  • project-directory/
    • index.html
    • js/
      • main.js
      • require.js
      • browser-screen.js
      • sso-override.js
      • sub/
        • util.js
        • jquery.js

Sample index.html file

<!DOCTYPE html>
        <title>My Project</title>
        <!-- data-main attribute tells require.js to load
             js/main.js after require.js loads. -->
        <script data-main="js/main" src="js/require.js"></script>
        <h1>My index.html file</h1>
        <p class="test">Some weird text here</p>

main.js – special configuration file in requireJS

  baseDir:'/js', // this dir will be used as home for our js files
  paths: {       // do not specify file extension, it assumes that it is .js
    'jquery':           'sub/jquery',  
    'text':             '/bower/text/text',
    'localized':        '/bower/webmaker-i18n/localized',
    'languages':        '/bower/webmaker-language-picker/js/languages',
    'list':             '/bower/listjs/dist/list.min',
    'fuzzySearch':      '/bower/list.fuzzysearch.js/dist/list.fuzzysearch.min',
    'browser-screen':   'browser-screen',
    'sso-override':     'sso-override',
    'utils':            'sub/utils'

// Now you specify which scripts will be loaded after require.js is fired in index.html
require(['browser-screen', 'sso-override', 'jquery', 'utils'],
  // you can give more instructions here

Now, inside one of your js file, you do the following.

require(['jquery'], function($) {
  $(.test).text("your new text");

With this example, you don’t need to include jQuery script in html file. This approach is really efficient in terms of coding, speed of application and code management. Also, it is much more easier to add more functionality in the future with such application structure.

Also, during this week, I pushed to PR and merged small css bug where I had to fix the alignment in navigation area when user logged in.

I am looking forward to continue my contribution to Mozilla and CDOT 🙂 Cheers!


The study week was quick and useful at the same time. I was catching up with everything and did a couple of progress with my own project. At the same time I am closer and closer to implementing CSP into webmaker and its components.

During my release #4 time, I am working on goggles and thimble components. The first thing I decided to implement is to file all the issues related to inline scripts and other bugs that could be problematic for CSP implementation.

Bugs in goggles:

  • Move google analytics into separate file X-Ray Goggles bug977293 – FILED, FIXED, MERGED
  • Move inline script into separate file bug975628 – FILED, FIXED, MERGED
  • Move error tracking into separate file bug973112 – REVIEWED,FIXED,MERGED
  • Move inline script in sso-override.html file into separate file bug980160 – FILED, IN PROCESS
  • Move inline script in webmaker-auth-client.html file into separate file bug980159 – FILED, IN PROCESS
  • Move inline script in preferences.html into separate file bug980162 – FILED, IN PROCESS
  • Also this directory has some html files with inline scripts. Thinking of moving them into separate files as well

Bugs in Thimble

Separate bugs

  • Remove old-style players and dependencies on the Popcorn.player module bug973369 – REVIEWED, FIXED, MERGED
  • Looking for some backend/new feature bugs, that I would like to work on. Maybe will catch up on filer.. still looking for something.

To sum up, I am moving forward to implement CSP for goggles, almost all sub bugs were fixed and merged. Now testing CSP work and looking for more inline script or other problems that could prevent from CSP integration.

At the same time doing the same thing with Thimble and hopefully soon Webmaker will be with CSP.
See you later with my final Release #4.

Good day!
Open Source Development is becoming more and more familiar to me. Thanks CDOT for that. 🙂
Lets get closer to my bugs for this release and what should be done by Friday, Feb 21st. During the last week I was assigned to some new bugs which are related to CSP implementation into Webmaker components(thimble, goggles, webmaker):

  • Moving inline script to separate file -> bug 973120
  • Remove inline script for quick-linking to a tag -> bug 973116 Fixed
  • Move google analytics snippet into a separate JS file -> bug 973119
  • Move JS error tracking snippet -> bug 973112

All these bugs should be resolved first, before I can start final CSP implementation into the webmaker components. That is why, once they will be resolved, I will start to work on this bugs:

Content Security Policy is a great feature that would be really beneficial to webmaker and maybe after could be implemented to other Open Source Projects. It is a standard and could be written in different languages. One more thing that I learned during my bug fixes is a data-* attribute that helps transporting variables from html file into separate .js file.
This is how it works:

In data-atr.html file

<!DOCTYPE html>
    <title>Testing Data-* attributes</title>
    <!--passing data here-->
    <!--you can pass any kind of data through the data-* attributes, really useful-->
    <script id="your-id" src="pathToFile.js" 
      data-anyVariable="I like to code"
      data-anyOtherVariable="That is how it works">

In pathToFile.js file

var first = document.getElementById("your-id").getAttribute("data-anyVariable");
var second = document.getElementById("your-id").getAttribute("data-anyOtherVariable");

//Now you can use variables from html
alert(first + "\n" + second);

I found a really good explanation and example here ->
See you later:)

Welcome to Friday evening…The last day of January outside, and winter is still here…I am getting more and more familiar with OpenSource Development and Mozilla in particular, however much more ahead and much much more I want to get… Working on Content Security Policy (CSP) is still in the process, however some issues are still not resolved.

This week I learned a lot of new for me, in particular:

  • How to use bower. (My job was to package nav.css with bower)

    Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. There are no system wide dependencies, no dependencies are shared between different apps, and the dependency tree is flat. From ->

    • First step is to create a repo on Github with a nav.css file
    • Next is to give a tag to a commit. (Learned some about Versions as well) Also this article helps with version understanding -> About Versions Thanks Jon Buckley for the link.
    • After that, you have to edit bower.json file inside all required webmaker components, which are using nav.css
    • Change path inside html pages, which are using nav.css file, to bower package path
    • Check all the pages and test
    • If something wrong, or nav.css file is damaged, you will have to change it in your repo (change the version as well) and change version inside bower.json file as well, to make changes happen.
    • Commit all the updates and do the PR.
  • Squashing commits – basically, it is when you are fixing some bug and committing small things about the same problem. After such work, you end up with 10 commits, which are useless. Here is where commit squashing take place. It puts many commits into one. Here is how it works: git rebase -i HEAD~3 This example will squash last 3 commits. After calling this command Text Editor will be opened (vim, sublime, etc.) and you will have to specify some options. You can find good tutorial here -> Squashing commits
  • Looked through Google Map API. Started my own example of it.

Right now thinking of getting a bug more concerning js backend..Hopefully will find one soon. Also my thanks to Jon Buckley for his help and patience 🙂

See you..