Disclaimer

The views expressed in this blog are my own and do not necessarily reflect the views of Oracle Corporation. All content is provided on an 'as is' basis, without warranties or conditions of any kind, either express or implied, including, without limitation, any warranties or conditions of title, non-infringement, merchantability, or fitness for a particular purpose. You are solely responsible for determining the appropriateness of using or redistributing and assume any risks.

By Joel Nation

There’s a few examples on the net about how to deploy a JET app to Application Container Cloud. All of these seem to either create an express app and then add oracle code to it later (eliminating the benefit of using grunt serve) or taking the compiled web folder and putting it into a new express application (making your devops or build automation slightly more painful). Let me show you an alternative.

This uses the basic http module in Node to create a very simple http server to serve our JET code from the web directory. If you run this using node server.js you should see your node app running, just like if you used grunt serve

You will also need to create a manifest.json file (and optional deployment.json file) to ensure ACC understands your request. The manifest file should look something like this:

Was recently helping a customer deploy Moodle on the Oracle Cloud with a focus on how to do this in automated way with Developer Cloud Service. I thought I’d share my experience in case anyone else is trying to do something similar.

Goal

We want to deploy Moodle (which is a PHP application that uses MySQL) on the Oracle Cloud and we want the build to be automatically triggered every night (so we can test it fresh).

Just a quick note on adding custom libraries to your Oracle JET (3.0 or greater) application. The steps are well documented on the Oracle Docs page, but it’s not clear why you are doing each step. So let me try and explain it to you.

Step 1: Get the library

First step run npm install <library> --save in your root directory to get the code into your project (ie: npm install knockout-date-bindings --save).

Step 2: Get it into your project

Now you need to make sure the code is added to generated code. Each time you run grunt serve or grunt build your code is packaged up into the ‘staging’ directory. This will differ depending on if you are creating a hybrid app or a web app. It’s either at hybrid/www or /www. You need to tell Oracle JET to include the code you downloaded in step 1 into this staging directory.

To do so, edit scripts/grunt/config/oraclejet-build.js and add an entry to the copyCustomLibsToStaging array (you may need to uncomment it if this is your first third party library). Eg:

src: Is what you want to copy. I generally just copy everything, but to minimise space, you could just copy *.js files

dest: Is where this code will be copied to (your staging directory).

If you run grunt build at this stage you should see your code being copied into your staging directory

Step 3: Tell require about it

You’ve downloaded the code and told JET about it, but now your actual code needs to know about it. Since it’s copied into your staging directory, just modify main.js to point to the location. In my case – add the following to main.js:

You will also need to update the main-*-paths.json files. These are used when you are building for development, production etc. You will generally refer to the full files in development and the min files in production.

Deploying custom code to the Oracle Mobile Cloud Service can be a lesson in frustration. You have to download the scaffold, write your code, zip it up and then upload that using the Web UI. You quickly get into the flow of doing this, but if you need to check logs or look at any other screen in MCS you will have to re-navigate back to the implementation screen over and over again.

Turns out that the MCS team has created a command-line npm tool to help with. This may be obvious to some, but it’s not highlighted well enough in my opinion! So to help others with this issue, let me show you how we use it.

First download any of the MCS SDKs and the navigate on the command line to the mcs-deploy folder. Then simply run npm install -g to install the mcs-deploy programme into your path.

Now navigate to your MCS project and make sure you’ve filled out the toolsConfig.json file. At a minimum you want to add the baseUrl and authorization parameters (they will have placeholders initially). This should be easy enough to fill in, most of the parameters are in the settings page of your mobile backend.

With that done, to upload your code just run the following on your command line (from within the implementation code folder):

mcs-deploy toolsConfig.json -u <username> -p <password>

This programme will package up your code and send it to MCS using the REST APIs. You can optionally leave off the username and password details and it will ask you for those interactively. It would be great if mcs-deploy could read these from a configuration file (say ~/.mcs-deply, much like my equivalent deploy tool for Application Container Cloud). That way you could include the script in your build tools without having to hard-code or change credentials.

This has already saved me a heap of time!

If the MCS Devs are reading this, it would be great if the mcs-deploy code was a proper npm package. It would mean we could install this just using npm install -g mcs-deploy (without having to download the SDK).

The latest version of Oracle’s Application Development Platform was just released and with it bring’s Ruby support for Application Container Cloud Service! As a fan of ruby (scaffolding is the best!) this is great news. The ruby image comes from DockerHub, so in future we should hopefully receive a lot more languages.

Along with Java, Node, PHP, Python and now Ruby ACC is turning into a great polyglot development platform. I haven’t had a chance to play with it much, but once I get some of my ruby apps running I’ll post an update. In the meantime, here’s some screenshots to whet your appetite.

I’ve been playing with Oracle JET (and Oracle Mobile Cloud Service) to build a demo application for a customer (I’ll post on that later). I’ve learnt a few things along the way and I’ll post these under Lessons Learnt for all to share.

One of the issues I ran into whilst building my JET app is that I hate the coding standard the JET team seems to use. They like curly braces on a new line and I prefer them on the same line. Now this is normally just one of those vi vs emacs style debates, but after fixing the auto-generated main.js file to suit my style I ran into a problem. When I went to build my code for release (using grunt build:release --platform=ios) I got an error in the uglifyjs task (Unexpected token: punc ({).

Turns out the `//injector:mainReleasePaths` and `//endinjector` comments in the main.js file actually do something! The JET build process will insert the paths from your main-release-paths.json file between these two comments. If you fiddle with the location of the curly braces then the generated code will be invalid.

So lesson learnt: you can enforce your standard on JET, but watch out for injector comments in main.js!

In this series I’m going to show you how to use the Fog Cloud Abstraction Library to manage cloud services in code (or on the command line). Fog is a ruby library that allows you to interact with multiple cloud providers (AWS, Azure, Oracle etc) through code. It abstracts away the complexities of each providers APIs and authentication mechanisms and attempts to make it easier to deal with networks, servers etc.

In this post I’m going to take you through setting up Fog and getting a listing of servers in an Oracle Cloud account (the process for Azure, AWS etc is very similar).