Webmaker Workshop with young students

Yesterday, Rick and I went to a middle school in the Toronto District School Board to do a Webmaker workshop for students in grade 6, 7 and 8.

We had three goals for this workshop:

  1. Get the students interested in considering a career as a software developer or a programmer.
  2. Educate them about the web.
  3. Teach them about Webmaker.org

There were many challenges in holding this workshop:

The students were very young.

Although grade 6–8 is the best age to educate students about something that could make them interested in their future, it might have been a boring workshop for some of them.

Photo from telegraph

Working at the school computer lab

Some of you might not know that working in a school computer lab is a nightmare when you have to access the internet. Why is that? Simply because some computers don't even have have Firefox or Chrome and you have to work with Internet Explorer 8. I'm sure you wouldn't have a good time working on Internet Explorer even with with version 9 or 10.

Working with many students at once

This is not really hard if you have patience. But, let me tell you that working with 30 students each workshop (we had 3 workshops) and trying to teac has never be an easy job for many of us... When I was that age, I didn't really have much of interest in learning about something new when I was on my computer. I just wanted to play Pokemon or something to kill some time.

Photo from BBC

How did we deal with that many students and did we succeed in our goals?

Holding three workshops with 30 students each was not easy for me since it was my first time doing this, but I did handle it very well. I also have to thank Rick for coming to the workshop to help me. It wouldn't have been as easy to do everything myself.

So how did we do it? Our first workshop was a bit of a mess because we didn't know we would be working in the computer lab. We also didn't know what the students were interested in or their knowledge of the web. However, we did learn from our first workshop. We had 15 minutes before the second workshop to prepare.

Let me list the things we didn't do well in our first workshop:

  1. We don't know how many students were coming. We expected there would be around 20 students, but there were definitely more. If I can recall the first workshop we had around 30+.

  2. The computers were very slow and really hard to work with. Thankfully Webmaker.org works really well on a slow computer as long as we have access to Firefox or Chrome (we only had access to Chrome which is fine too).

  3. We were short of time. We didn't know students would need us to answer their passport survey (a survey about the job). Since we wanted to cover three of our main goals, the timeframe we had (40 minutes) wasn't enough at all.

  4. We couldn't get most of the students' attention. It's hard to do that, but we had a plan – to give away some t-shirts. Unfortunately, it failed because we didn't have enough time.

Like I said, we did learn from our first workshop, so in that 15 mins we had before the second workshop, we did a quick plan on what we wanted them to do and what we wanted to tell them.

The second and third workshop we did went very well!

  1. We got 90% of students' attention. We made sure we covered things that they needed to get done first (their passport survey) and asked them to pay attention to our workshop because we had a prize. When we said that everyone just went super quiet and paid full attention to what we were showing them.

  2. They did learn something. I told them if they wanted to win the prize they would have to make sure they knew what was going on. At least 70% of them could answer our questions!

  3. They made something on Webmaker.org using Thimble. Well this is because we asked them to make something so they could win the prize...

4: We were on time! Hooray.

Just to conclude, we were really happy to see the smiles on the students' faces when they published a make on Webmaker.org and when they won a prize. I felt super happy and I'm sure what we did will influence this young new generation of kids to a have better future.

Yesterday, Rick and I went to a middle school in the Toronto District School Board to do a Webmaker workshop for students in grade 6, 7 and 8. We had three goals for this workshop: Get the students interested in considering a career as a software developer or a programmer…

Read More

Why you should use "dir" attribute more for right to left localization

So, in the past week I have been working on the implemetation for right to left localization on one of Mozilla Webmaker tool call Popcorn Maker and I have struggled a lot and having real hard time working on making the tool right to left compatible because...

Popcorn Maker is a Video Editor. I've done a lot of research and got some user input and discussed on how right to left being done with video player or video editor and most of right to left users preferred that it's the same as left to right language. Therefore I have to keep some part of the site to be same as LTR and the rest RTL.

If you have read my previous blog post about right to left localization using CSS selector and some library such as CSSJanus to convert properties and values in CSS from one direction to the other so it can be use for Right to left languages. Now, that is not really going to work in this case because we can't automate everything since we want to have some part of the site to have the same style with LTR.

Also, when you use dir attribute on <html> tag and if the direction is rtl the browser will try to render most of the element that was from one side to the other and this is really useful but most of the time we will just use this life-saver attribute on <html> tag and that's it, but if you don't already know dir attribute can be used in other element as well and this is why I think we should use this more.

Now, let's why and how this can be life-saver for many of you who's working on right to left and wants to make sure you can save some time battling with CSS.

I have this snippet:

<!doctype html>  
<html dir="rtl">  
  <head>
      <meta charset="utf-8">
    <title>Your Awesome Webpage</title>
  </head>
  <body>
    <p dir="ltr">This text will be on the left</p>
    <p>This text will be on the right</p>
  </body>
</html>

So:

This text will be on the left

This text will be on the right


As you can see from example above that we have two <p> tag and one is being override by dir="ltr" and the other one is being control by <html dir="rtl">.

That is one of the usefulness of the attribute where we can have mixed direction in the same page and not having to worry about writing a lot of CSS to control the direction yourself when the browser have this functionality by default.

Another example:

<p dir="ltr">The bulk of the content is in English and flows left to right,  
until this phrase in Arabic makes an appearance,  
<span lang="ar" dir="rtl">مرحبا</span> (meaning hello), which  
needs to be set to read right-to-left.</p>  

The bulk of the content is in English and flows left to right, until this phrase in Arabic makes an appearance, مرحبا (meaning hello), which needs to be set to read right-to-left.

Also, note that the dir attribute cannot be applied to the following elements:

  • applet
  • base
  • basefont
  • bdo
  • br
  • frame
  • frameset
  • iframe
  • param
  • script

So, generally dir attribute is really useful and will save you a lot of times when working on localization especially when you have to deal with bidirectional.

You can read more from MDN about dir attribute here.

So, in the past week I have been working on the implemetation for right to left localization on one of Mozilla Webmaker tool call Popcorn Maker and I have struggled a lot and having real hard time working on making the tool right to left compatible because... Popcorn Maker is…

Read More

Seneca CDOT Faculty and Student Open House V2

On November 21, 2013 we had an Open House at CDOT for Faculty and Student about various open source projects and yesterday is our 2nd Open House here at CDOT and I had a chance to present my work that I have done for Mozilla Webmaker to Students and Faculty here at Seneca College @York.

Last time when I present my work, mainly it was about the tools that we have on Webmaker and try to explain what our tool does and what is the goal for Mozilla.

So, this time I got more to present since it has been four months since last Open House and I did show a lot of our works that have been completed such as our new localization across our tools, new improved Thimble app, Popcorn Maker and X-Ray Goggles. Also, I have introduced to our workflow specifically in our team how we work in an open such as: using IRC to community, or github to collaborate with coding.

Again... I was super busy with explaining/talking with students and faculty and didn't have a chance to take any photo, but this time I must say it was better than last time. Hopefully we will have another one again soon and with more people :)

On November 21, 2013 we had an Open House at CDOT for Faculty and Student about various open source projects and yesterday is our 2nd Open House here at CDOT and I had a chance to present my work that I have done for Mozilla Webmaker to Students and Faculty…

Read More

How to localized AngularJS app

So, the past week I've been working on localizing new Webmaker's event page which was written in AngularJs and that is one of my biggest challenge because I'm not very expert with AngularJs and have to come up with a solution for localization in AngularJs based app within a very short period of time.

I've spent a lot of time planning and thinking if I should write my own DIY localization module or use something that's already out there, and finally I have found something and I thought I should share this with you guys.

I've found an Angularjs LocalizationServer written by Jim Lavin which was a really good start for me because I don't have to go through and understand everything in Angular to write my own module for localization from ground up and Jim's module was very similar to what we're using in our node app, so I took it and did a lot modification for our needs at Webmaker.

This i18n.js file can simply be include in your app and with few setup as I'm going to go through in this post and you will be ready to go with your AngularJs i18n.

Though, at first this module can be independently included and use, but I've chose to rely on our node-i18n to provide some accuracy on language request and to serve the translation file the same way we have for other apps simply because we want that file to be supported by Transifex so we can get our community to help us translate.

So, let's look at how to do it if you want to include this library in your app.

Step 01: Download that i18n.js file from this link
Step 02: Include this i18n.js file in your app directory or anywhere as you wish

app/js  
├── app.js
├── controllers.js
├── directives.js
├── filters.js
├── i18n.js
└── services.js

Step 03: In your index.html make sure you have i18n.js included in your app.

  <script src="js/i18n.js"></script>

Step 04: Now you have to make sure you include the i18n Angular module in your module list

angular.module('myApp', [  
  'ngRoute',
  'ngResource',
  'ngAnimate',
  'ui.bootstrap',
  'localization', // Here
  'myApp.filters',
  'myApp.services',
  'myApp.directives',
  'myApp.controllers'
])
...
...

This is pretty much done for including the module, but in order to use this version of the module we need to use that node-i18n module that I've mentioed above since we want the translation file and the locale information.

In your backend server include this module

  var i18n = require('webmaker-i18n');

And you can use this:

  // Setup locales with i18n
  app.use( i18n.middleware({
    supported_languages: env.get('SUPPORTED_LANGS') || [defaultLang],
    default_lang: defaultLang,
    mappings: require('webmaker-locale-mapping'),
    translation_directory: path.resolve(__dirname, '../locale')
  }));

This will now allow you to have access to your translation file which located in your root directory

locale  
├── en_US
│   └── events2.json
└── th_TH
    └── events2.json

The format we use here is Chrome.i18n json file

{
  "_Welcome_home_page_": {
    "message": "Welcome to Webmaker Events.",
    "description": "Home page greeting text"
  },
  "_Sub_home_page_": {
    "message": "(Add super fun imagery here.)",
    "description": "Sub message in home page"
  }
}

With the setup of our node-i18n and i18n.js for AngularJS we will also have to setup the route for translation file and with our node-i18n module we have API that allow that to be expose with express by simply use StringsRoute method.

app.get( "/strings/:lang?", i18n.stringsRoute( "en-US" ) );  

So, when we acess http://yourdomain.com/strings/en-US that will return JSON object for that specific language.

And as you can see from this i18n.js file on line 32 where we make a request to get our translation file.

One last thing before we can go to localize any of our template file is to have language information available throughout our app.

What I did was to have a config file in our template file let say config.js which is acessible by URL and what I meant by that? here let see the example in your backend file

  var config = {};
  // Serve up virtual configuration "file"
  app.get('/config.js', function (req, res) {
    config.lang = req.localeInfo.lang;
    config.direction = req.localeInfo.direction;
    config.defaultLang = defaultLang;
    config.supported_languages = i18n.getSupportLanguages();
    res.setHeader('Content-type', 'text/javascript');
    res.send('window.eventsConfig = ' + JSON.stringify(config));
  });

And in your template file just have this line include:

  <script src="config.js"></script>

Now we have to make sure that the above is a relative path because we are going to allow user to change language from the requested URL such as: http://yourdomain.com/th-TH/# if their browser's language preference was set to other language.

Last but not least you will have to include that config.lang in your $rootScope so that it will be accessible by i18n.js file

In your services.js include this as constant

angular.module('myApp.services', ['ngResource'])  
  .constant('config', window.eventsConfig) // Here
  .factory('eventService', ['$rootScope', '$resource', 'config',
    function ($rootScope, $resource, config) {
      return $resource(config.eventsLocation + '/events/:id', null, {
        update: {
          method: 'PUT'
        }
      });
    }
  ])

Then here come the magic

      // Set locale information
      if(config.supported_languages.indexOf(config.lang) > 0) {
        $rootScope.lang = config.lang;
      } else {
        $rootScope.lang = config.defaultLang;
      }
      $rootScope.direction = config.direction;

So now you will have lang and other language information available in the scope and template.

Ok, so let's start with localizing some text in our template file.

We have three methods here.

First:

{{ '_toggle_navigation_' | i18n }}

Second:

<title ng-bind="'_webmaker_events_' | i18n"></title>  

Thrid:

<span ng-bind-html="'_webmaker_welcome_' | i18n"></title>  

Fourth:

<span bind-unsafe-html="'_agree_to_terms_and_conditions_' | i18n"></span>  

Now let's see the explaination for these three and how it's being use.

For the first method it's very straightforward where we have our braces around with key_name in that single quote you can name anything as long as it's match with the translation file.

Second one is the biding it with the element itself and for this case you want to use it when you just want to make sure things happen only when template is ready.

Third one is when you have some markup and you want that to be display as markup and not being escape by Angular.

Fourth one you will see the word unsafe and felt a bit scary, but here is the use case for this one.

If you have variable in your value such as

"_agree_to_terms_and_conditions_": {  
    "message": "I agree to your <a href=\"https://webmaker.org/{{lang}}/terms\">terms</a> and <a href=\"https://webmaker.org/{{lang}}/privacy\">conditions</a>",
    "description": "Agree to terms and condition message"
  }

If you don't use this method it will simply be escape by Angular and your value won't be render correctly and what we have there it will tell it to use $compile for that one call that we are watching and just rerender that again. You can look at the code from line 126-148.

That's it people you can now start localizing your apps and happy localizing :)

If you have any question please feel free to drop me a comment here.

So, the past week I've been working on localizing new Webmaker's event page which was written in AngularJs and that is one of my biggest challenge because I'm not very expert with AngularJs and have to come up with a solution for localization in AngularJs based app within a very…

Read More

Right to left localization with pure CSS selectors

So this week I've spent most of my times working on right-to-left localization on Webmaker.org and thought I should write some blog post to update and share what I have learned so far with right to left.

This is the Left to right version of the site

Withoht the magic of the CSS this is what happening when we are doing right to left

So now we use some LESS library call rtltr-for-less which will basically parse our LESS file and try to convert any properies and values that is a direction to the opposite for instance if:

.ClassName {
    text-align: left;
    margin-right: 20px;
    padding: 30px 20px 0 20p
}

It should now be

.ClassName {
    text-align: right;
    margin-left: 20px;
    padding: 30px 20px 0 20p
}

Then our result after this trick we are getting something like this

Now as you can see things getting much better and in the right position but!!! there are things that you will need to polish and especially images like the sign in button that we need to have some more code to apply to make it right.

With images what I have learn we can use CSS Transform to flip the image. In right to left almost everything is just the mirror of left to right, so we can do something like:

    -webkit-transform: scaleX(-1);
    transform: scaleX(-1);

With that it will flip the image to the other side.

Also, with the banner (Green and Yellow one) as you can see they are in the wrong direction because how it is rotate in ltr was

    transform: rotate(-45deg);

So I have to change it the opposite by making it positive

    transform: rotate(45deg);

But the question was how can I make this dynamic? Because we want one style for LTR and the other for RTL?

I've learned that I can use pseudo CSS selector to apply a specific style for each one and this is how I did it

In the HTML element I have to specify the direction, so what it was originally is:

<div class="banner">  
      Some text here
</div>  

So I added dir="{{localeInfo.direction}}" in to the element (This is a variable from our templating engine, so it will detect the language and return either ltr or rtl depend on the request.

This is what we have now

<div dir="{{localeInfo.direction}}" class="banner">  
      Some text here
</div>  

Or

<div dir="rtl" class="banner">  
      Some text here
</div>  

And with CSS all we need to do is using this CSS selector with our dir

So now we have

  .banner[dir="rtl"] {
    transform: rotate(45deg);
    -webkit-transform: rotate(45deg);
  }

So after the trick!

As you can see we have a final product that is nice and clean for RTL without effecting the LTR one :)

So this week I've spent most of my times working on right-to-left localization on Webmaker.org and thought I should write some blog post to update and share what I have learned so far with right to left. This is the Left to right version of the site Withoht the…

Read More

How to automatically run elasticsearch on Startup for Mac OS X

If you are like me you want most of the things to be automate like my previous post showing you how to run MongoDB on StartUp for Mac OS X, and this post I'm going to show you how to do that for elasticsearch.

Assuming you had elasticsearch installed (by HomeBrew).

If you simply run this:

ln -sfv /usr/local/opt/elasticsearch/*.plist ~/Library/LaunchAgents  

And try restart your Mac or your terminal you will see that your elasticsearch service has been started and ready to work on.

I'm don't think this will work for one that you install with MacPort or manual install, but this is the file:

<?xml version="1.0" encoding="UTF-8"?>  
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">  
<plist version="1.0">  
  <dict>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>homebrew.mxcl.elasticsearch</string>
    <key>ProgramArguments</key>
    <array>
      <string>/usr/local/bin/elasticsearch</string>
      <string>-f</string>
      <string>-D es.config=/usr/local/Cellar/elasticsearch/0.90.11/config/elasticsearch.yml</string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
      <key>ES_JAVA_OPTS</key>
      <string>-Xss200000</string>
    </dict>
    <key>RunAtLoad</key>
    <true/>
    <key>WorkingDirectory</key>
    <string>/usr/local/var</string>
    <key>StandardErrorPath</key>
    <string>/dev/null</string>
    <key>StandardOutPath</key>
    <string>/dev/null</string>
  </dict>
</plist>  

It might work if you have that file link and make sure all the path is correct above.

If you are like me you want most of the things to be automate like my previous post showing you how to run MongoDB on StartUp for Mac OS X, and this post I'm going to show you how to do that for elasticsearch. Assuming you had elasticsearch installed (by…

Read More