Use NPAPI plugins in Chrome Ver.42 and later

NPAPI support by Chrome     http://www.java.com/en/download/faq/chrome.xml

The Java plug-in for web browsers relies on the cross platform plugin architecture NPAPI, which has long been, and currently is, supported by all major web browsers. Google announced in September 2013 plans to remove NPAPI support from Chrome by “the end of 2014”, thus effectively dropping support for Silverlight, Java, Facebook Video and other similar NPAPI based plugins. Recently, Google has revised their plans and now state that they plan to completely remove NPAPI by late 2015. As it is unclear if these dates will be further extended or not, we strongly recommend Java users consider alternatives to Chrome as soon as possible. Instead, we recommend Firefox, Internet Explorer and Safari as longer-term options. As of April 2015, starting with Chrome Version 42, Google has added an additional step to configuring NPAPI based plugins like Java to run — see the section Enabling NPAPI in Chrome Version 42 and laterbelow.

Enabling NPAPI in Chrome Version 42 and later

As of Chrome Version 42, an additional configuration step is required to continue using NPAPI plugins.

  1. In your URL bar, enter:
    chrome://flags/#enable-npapi
  2. Click the Enable link for the Enable NPAPI configuration option.
  3. Click the Relaunch button that now appears at the bottom of the configuration page.

Developers and System administrators looking for alternative ways to support users of Chrome should see this blog, in particular “Running Web Start applications outside of a browser” and “Additional Deployment Options” section.

Schedule Tasks on Linux Using Crontab

Source:  http://kvz.io/blog/2007/07/29/schedule-tasks-on-linux-using-crontab/
By  Kevin van Zonneveld

If you’ve got a website that’s heavy on your web server, you might want to run some processes like generating thumbnails or enriching data in the background. This way it can not interfere with the user interface. Linux has a great program for this called cron. It allows tasks to be automatically run in the background at regular intervals. You could also use it to automatically create backups, synchronize files, schedule updates, and much more. Welcome to the wonderful world of crontab.

Crontab

The crontab (cron derives from chronos, Greek for time; tab stands for table) command, found in Unix and Unix-like operating systems, is used to schedule commands to be executed periodically. To see what crontabs are currently running on your system, you can open a terminal and run:

$ sudo crontab -l

To edit the list of cronjobs you can run:

$ sudo crontab -e

This wil open a the default editor (could be vi or pico, if you want you canchange the default editor) to let us manipulate the crontab. If you save and exit the editor, all your cronjobs are saved into crontab. Cronjobs are written in the following format:

* * * * * /bin/execute/this/script.sh

Scheduling explained

As you can see there are 5 stars. The stars represent different date parts in the following order:

  • minute (from 0 to 59)
  • hour (from 0 to 23)
  • day of month (from 1 to 31)
  • month (from 1 to 12)
  • day of week (from 0 to 6) (0=Sunday)

Execute every minute

If you leave the star, or asterisk, it means every. Maybe that’s a bit unclear. Let’s use the the previous example again:

* * * * * /bin/execute/this/script.sh

They are all still asterisks! So this means execute /bin/execute/this/script.sh:

  • every minute
  • of every hour
  • of every day of the month
  • of every month
  • and every day in the week.

In short: This script is being executed every minute. Without exception.

Execute every Friday 1AM

So if we want to schedule the script to run at 1AM every Friday, we would need the following cronjob:

0 1 * * 5 /bin/execute/this/script.sh

Get it? The script is now being executed when the system clock hits:

  • minute: 0
  • of hour: 1
  • of day of month: * (every day of month)
  • of month: * (every month)
  • and weekday: 5 (=Friday)

Execute on workdays 1AM

So if we want to schedule the script to Monday till Friday at 1 AM, we would need the following cronjob:

0 1 * * 1-5 /bin/execute/this/script.sh

Get it? The script is now being executed when the system clock hits:

  • minute: 0
  • of hour: 1
  • of day of month: * (every day of month)
  • of month: * (every month)
  • and weekday: 1-5 (=Monday til Friday)

Execute 10 past after every hour on the 1st of every month

Here’s another one, just for practicing

10 * 1 * * /bin/execute/this/script.sh

Fair enough, it takes some getting used to, but it offers great flexibility.

Neat scheduling tricks

What if you’d want to run something every 10 minutes? Well you could do this:

0,10,20,30,40,50 * * * * /bin/execute/this/script.sh

But crontab allows you to do this as well:

*/10 * * * * /bin/execute/this/script.sh

Which will do exactly the same. Can you do the the math? ; )

Special words

For the first (minute) field, you can also put in a keyword instead of a number:

@reboot     Run once, at startup
@yearly     Run once  a year     "0 0 1 1 *"
@annually   (same as  @yearly)
@monthly    Run once  a month    "0 0 1 * *"
@weekly     Run once  a week     "0 0 * * 0"
@daily      Run once  a day      "0 0 * * *"
@midnight   (same as  @daily)
@hourly     Run once  an hour    "0 * * * *"

Leaving the rest of the fields empty, this would be valid:

@daily /bin/execute/this/script.sh

Storing the crontab output

By default cron saves the output of /bin/execute/this/script.sh in the user’s mailbox (root in this case). But it’s prettier if the output is saved in a separate logfile. Here’s how:

*/10 * * * * /bin/execute/this/script.sh >> /var/log/script_output.log 2>&1

Explained

Linux can report on different levels. There’s standard output (STDOUT) and standard errors (STDERR). STDOUT is marked 1, STDERR is marked 2. So the following statement tells Linux to store STDERR in STDOUT as well, creating one datastream for messages & errors:

2>&1

Now that we have 1 output stream, we can pour it into a file. Where > will overwrite the file, >> will append to the file. In this case we’d like to to append:

>> /var/log/script_output.log

Mailing the crontab output

By default cron saves the output in the user’s mailbox (root in this case) on the local system. But you can also configure crontab to forward all output to a real email address by starting your crontab with the following line:

Mailing the crontab output of just one cronjob

If you’d rather receive only one cronjob’s output in your mail, make sure this package is installed:

$ aptitude install mailx

And change the cronjob like this:

*/10 * * * * /bin/execute/this/script.sh 2>&1 | mail -s "Cronjob ouput" .com

Trashing the crontab output

Now that’s easy:

*/10 * * * * /bin/execute/this/script.sh > /dev/null 2>&1

Just pipe all the output to the null device, also known as the black hole. On Unix-like operating systems, /dev/null is a special file that discards all data written to it.

Caveats

Many scripts are tested in a BASH environment with the PATH variable set. This way it’s possible your scripts work in your shell, but when run from cron (where the PATH variable is different), the script cannot find referenced executables, and fails.

It’s not the job of the script to set PATH, it’s the responsibility of the caller, so it can help to echo $PATH, and put PATH=

at the top of your cron files (right below MAILTO).

AngularJS in plain English

Controllers, Directives, and Services. AngularJS 101

Source: http://matthewcarriere.com/2015/01/13/controllers-directives-services-angularjs-101/

So you want to get into AngularJS. You’ve probably heard about it being a great framework or platform and that sounds like something you should be using. You might have seen a few great demos of data binding and wanted to incorporate that into your project. Then you take a look at the docs… you get lost. You read some things online and now your learning about dependency injection, model view controller, declarative programming…  maybe even lambda calculus. All you wanted to do was bind a variable into your page. Let me run you through the core concepts you should understand – you’ll be able to run with them and start developing with AngularJS right away.

So where do we start? Well we need some HTML. So let’s open up your favorite code editor and markup some HTML. I use Sublime Text. Here’s what you should type up.

1
2
3
4
5
6
7
8
<html>
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
    </head>
    <body>
    </body>
</html>

So what did we do here? Well for the most part its just some standard HTML markup. I also added a script tag that includes the angularjs file directly from a Google CDN. Why download it? If you save this file and load it in a browser, you won’t see anything, but you should be able to open up the developer console and type angular. This will return an object and you shouldn’t see any errors.

type-angular-no-errors

Ok great, we’ve setup AngularJS on our webpage and we’re ready to start writing some code! Let’s start with a controller.

Controllers

So what is a Controller? A Controller is an object that’s responsible for managing other objects. What that means is, the Controller doesn’t actually know the specifics about an object, like a Book for example. The Controller doesn’t know how many pages a Book has, who its author is or what its called, but it knows how to get a Book, how to ask it for its name or how to pass it to a View so it can be read. If you’re just getting started with AngularJS and Model-View-Controller architecture in general just remember that if your application has an object like a Book, chances are it will have a BooksController.

So for this simple application I want to ultimately display some weather for a specific city. So right away I know I am going to need to create a WeatherController to manage the Weather we request! Let’s do that now.

Go ahead and add another file to your application. Name this file app.js and update the markup in the html file you created earlier to include it:

1
2
3
4
5
6
7
8
9
<html>
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
    </body>
</html>

Great! Before we make our Controller we are going to have to make a top level module for it to live in. AngularJS projects are built around modules, so we will make one next. Open app.js and add the following code:

1
angular.module('weatherApp', []);

Save and refresh your html page. Take a look at the developer console. You shouldn’t have any errors and you should be able to retrieve your angular app by typing the following:

get-angular-module

Did you see the subtle difference there in Syntax? When you create a module, you add the square brackets [ ] but when you retrieve one, you don’t. This can trip you up when you’re getting started with AngularJS. So be careful. What are the brackets for? For including other modules! For the Ruby developers, you can think of them as a require.

Ok, so now we are going to add our Controller (finally!). I’m going to just add it to app.js. In a production application you would likely use the return value from this module statement and have other files that had the code for your controllers, services, and directives, but I’m gonna keep it simple for now.

Here’s how you go ahead and add your first AngularJS Controller!

1
2
3
4
angular.module('weatherApp', [])
  .controller("weatherController", function() {
    console.log('weather controller created!');
  });

There’s another small thing to notice here – I took the semicolon off the first line and chained the controller declaration after the module declaration. I added a simpleconsole.log statement to let us know that the controller has been loaded on the page. So let’s check that now.

Save and refresh your page. Nothing. That’s because we haven’t actually included that weatherApp module we created onto the page, to do that we need a directive!

Directives

Directives are simply custom html attributes that AngularJS knows what to do with. The browser will ignore them and Angular will use them. They are that simple. I know they are SO much more, but we are learning, and for the sake of getting started with Angular. That’s all you need to know for now. So let’s tell Angular to load our app. We do that by using a built-in directive named ng-app. Its common to put that on the HTML tag at the top of you page. Let’s do that now:

1
2
3
4
5
6
7
8
9
<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
    </body>
</html>

So again, if you save and refresh your page. Nothing. Ok, here’s the deal. We have told Angular about our app and Angular has in fact loaded it. If you don’t believe me go ahead and change the ng-app declaration from: ng-app=”weatherApp” to ng-app=”weatherApp1″. When you save and refresh the page you will see a horrible error message (get used to it – that’s one of the things that drives me nuts about Angular is the horrible error messages). Change the ng-app back and make sure you aren’t getting any errors. Now you believe me that the app was loaded, but where was that console statement? Well, we didn’t create the controller. Let’s go ahead and do that now. With another built-in directive named ng-controller!

Add ng-controller to the body tag:

1
2
3
4
5
6
7
8
9
<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body ng-controller="weatherController">
    </body>
</html>

Now if you save and refresh the page… you see the console message! Now that we have a controller there is a ton of cool stuff we can do. The first is to start using the scope and binding data to our html elements.

Data binding and scope

If you’ve done any jQuery before, you’ve probably written something like this:

1
$("p.description").text("Here is some text!");

This is simply finding a p tag with a class of description and binding the text Here is some text! inside it. It works, and its served us well. However, what can happen is this kind of code can be nested deep in a very large javascript application and the p tag, well it just has a class of description. We don’t know that this code is going to drive by and throw a value in it. It can be hard to trace back why some elements behave the way they do on a page. Imagine if this p tag didn’t even have a class of description. It was just a p tag! This is where declarative programming and data binding comes in.

In Angular we actually declare what we are binding to an element, it makes it much easier to understand what markup is going to be affected by our code and what the intention of the original developer was. So let’s go ahead and add a p tag to our webpage and write out a brief description of our app using Angular declarative programming:

1
2
3
4
5
6
7
8
9
10
<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body ng-controller="weatherController">
        <p ng-bind="description"></p>
    </body>
</html>

You know the drill. Save and refresh. Nothing. Don’t hate me. The reason is because Angular looked in the current scope of the directive (in this case the ng-controller named weatherController) and found nothing. So, you got nothing. Let’s go into our controller and add the description variable to the scope now:

1
2
3
4
angular.module('weatherApp', [])
  .controller("weatherController", function($scope) {
    $scope.description = "a simple weather app";
  });

There are two changes to notice here. First, we added a parameter to the constructor function of our controller named $scope. Second, we used that parameter as an object and added our description variable onto it. We gave it a simple value of: a simple weather app. What was that $scope parameter we passed to our constructor function? Well it was basically a service that gave us access to the current scope. What’s a scope? Well for right now, a scope is basically anything inside the element our directive is declared on. So, we declared our controller on the body tag. That means whatever we put inside the body tag is in the current scope when we are working inside our weatherController. Don’t believe me? Try this: add a div tag inside the body. Move the ng-controller declaration onto that div tag. Finally, move the p tag with our description outside the div, like this:

1
2
3
4
5
6
7
8
9
10
11
<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
        <p ng-bind="description"></p>
        <div ng-controller="weatherController"></div>
    </body>
</html>

Here we go again… save and refresh. Nothing. That’s because our p tag is outside the scope of the controller now. I hope that’s becoming more clear. Basically if you want to bind something to the page then it needs to be on the $scope object. The $scope object is relevant to everything inside the element that you declared the directive on. In case you are wondering if you can have nested scopes. Yes. You can. So now that we have used a couple built-in directives, lets create our own. A custom directive!

Custom Directives

Why would we want to build our own Directive? Well, suppose we have a lot more functionality inside our weatherController. Suppose it has a few Controllers and a Service or two. We might find it useful to re-use that weather on multiple pages. We don’t want to markup all the necessary elements every time on every page, so we use a directive. Adding a directive let’s us use templates so we can define the markup we need for weather once in its own file. Adding a directive also allows us to make changes to our code in one place and everywhere the directive is used is updated with the new functionality. Directives are really powerful and one of the best parts of Angular.

Adding a Directive to our app.js is very similar to adding a Controller. Here’s what app.js looks like now:

1
2
3
4
5
6
7
8
9
10
angular.module('weatherApp', [])
  .controller("weatherController", function($scope) {
    $scope.description = "a simple weather app";
  })
  .directive("weather", function() {
    return {
      restrict: "A",
      templateUrl: "weather.html"
    }
  });

This one is a little bit different than the controller in that it returns an object. That object has a bunch of parameters necessary for the directive to function. I’ve kept it simple and only added the bare minimum. First, I set the restrict property to “A”. This means the directive will function as an attribute of an element. This means I will put it on HTML elements just like ng-app or ng-controller. Second, I set templateUrl to a file named weather.html. This is the file that will hold the markup we used to have sitting in our body tag. Lets create that file next. Add the following code to weather.html:

1
2
3
<div ng-controller="weatherController">
 <p ng-bind="description"></p>
</div>

I’ve created a div tag here to declare the controller on. You could also have added the controller property to our directive and omitted this all together. Other than that, this file is pretty simple. Finally, let’s update our original HTML file to use our new directive:

1
2
3
4
5
6
7
8
9
10
<html ng-app="weatherApp">
    <head>
        <title>My First Angular App!</title>
        <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.28/angular.min.js"></script>
        <script type="text/javascript" src="app.js"></script>
    </head>
    <body>
        <div weather></div>
    </body>
</html>

I love how simple that is! Basically anywhere I want to add my weather app, I just add that directive now.

Now before you run this, let me tell you what sucks. If you try to refresh this in Chrome you will get a huge ugly Cross Origin error in your console, like this:

cross-origin-error

Unfortunately, Chrome won’t let you reference local files. You can go ahead and work from Safari or you can run the following command inside your terminal window to open Chrome with this security disabled:

1
open -a Google\ Chrome --args --disable-web-security -–allow-file-access-from-files

Once you open you app again in Safari, or using the above command, you should see the same message as before, but now using your own custom directive! The last thing we need to do is add a Service.

Services

So we created a controller to manage our application and give us access to the scope. We placed all that functionality inside a Directive to allow us to re-use it and template out our markup. Where do we make a call to get our actual Weather? If you are thinking you would simply add a function to our controller and place the result on the scope… you’re not being very Angular! What I mean is that would work. You could simply call a web service right inside your controller and get your weather data, but Angular gives us Services to extract the functionality of getting our objects, calling web services etc. Its the preferred place to put that sort of logic.

Why else should you use a service? First, Reuse! You will likely create a service that is helpful to not only this controller, but to other controllers in your application. Or even a Directive (yes directives can be passed services). Second, maintenance. This controller example is trivial, but your actual projects will create very large controllers without cluttering them with service calls and the logic required to get and set objects.

So how do we add a Service? Well, again its very similar to the other pieces we’ve added to our application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
angular.module('weatherApp', [])
  .service("weatherService", function() {
    this.getWeather = function(cityName) {
      return "30";
    };
  })
  .controller("weatherController", function($scope, weatherService) {
    $scope.description = "a simple weather app";
    $scope.temp = weatherService.getWeather("Vancouver");
  })
  .directive("weather", function() {
    return {
      restrict: "A",
      templateUrl: "weather.html"
    }
  });

There’s a few items to take note of here. One, our service declares its function on this. Because of the way constructor functions work, you need to declare your functions on thisif you want them to be accessible. If you didn’t declare it on this you wouldn’t be able to call it in the Controller. Second, we added our service to the list of parameters in our controllers’ constructor function. Finally, we created a scope variable named temp and placed the value returned from our Service call. Now I know I didn’t actually make a Service call. That’s the subject for another blog post, or a challenge for the reader.

The final piece is to update our template file with the new scope variable we created:

1
2
3
4
<div ng-controller="weatherController">
  <p ng-bind="description"></p>
  <p ng-bind="temp"></p>
</div>

If you save and refresh you will see your simple description and you’re hard-coded temperature. This was a simple and not very functional example, but the point was to help you understand the building blocks of an AngularJS application. With Controllers, Services and Directives and a basic understanding of scopes and declarative programming, you are should now be able to start to put together your first real AngularJS application!