Read Rajeev S Badgujar's answer to Which NOSQL database should I learn? on Quora

Should you upgrade to macOS Sierra?

I own a 13" MacBook Pro early 2015 model with El Capitan.  Being a software engineer it served my purpose well and then came the much hyped macOS Sierra. I being an early adapter took the risk of upgrading. Lets see some ups and downs of macOS Sierra.

1. Battery Backup : The 13" MacBook claims 10 hours backup while I noticed upto 11 hours after upgrade to Sierra. This came as a big surprise. Certainly loved it.
Rating : 1 apples

2. Tabs : Being developer, its pain working through multiple windows of most of the apps. Tabs comes as a great relief :) Thanks Apple.
Rating : 2 apples

3. iCloud Drive : Another thoughtful feature by Apple. iCloud Drive helps backup rarely used files to cloud drive so that your MacBook Pro is always clutter free, plus you get to access the files whenever you want and from any other Apple device.
Rating : 2 apples

1. Siri : The much hyped feature of Sierra is of good but not great. It does not add any value to a developers life. It does the job for a normal user but disappoints a power user. Its not consistent either. I asked repeatedly about available storage and every time I got different answer while the "About This Mac" showed a different value.

Rating : 1/2 apple

2. USB Ethernet connector : After the upgrade my USB Ethernet connector stopped working. I googled but could not find any useful information. Took the mac to Apple store only to find out that its a known issue and there is no clarity when and who (Apple or Vendor) will fix it. Sad.
Rating : -2 apple

I did not use other features like Universal Clipboard, Log in via Apple Watch as I have only one Apple device. These features are not very helpful for developers.

So one can live without upgrading to macOS Sierra or at least wait for some more updates to be released by Apple.

Comparison of the methods of Binary deployment to OpenShift

This is the last writeup in the 4 part series on binary deployments to OpenShift. You can find previous posts with detailed discussion on each approach at

Part 1 - Binary deployment to OpenShift
Part 2 - Binary deployment to OpenShift using rsync
Part 3 - Binary deployment to OpenShift Using GIT

Comparison

Approach	Openshift as Jenkins slave	Behavior	Advantages	Limitations
Deploy using rsync	No	Generated war is directly deployed to Openshift application’s runtime.	1. It is simple unix command. 2. Only working solution currently, approach suggested by Redhat support.	1. It requires an openshift application pre-created. Tooling required to configure the UUID of the application to be copied to Jenkins job. 2. No rollback support will be provided since we are copying the war manually.
Openshift’s rhc commands	No	Generated war is packaged in .zip/.gz and same can be deployed to pre-created application.	1. Rollback support provided by Openshift. 2. It could also ensure to sync the war to other openshift gears of the same application 3. Openshift supported command.	1. Need tooling/gradle task to create the openshift typical structure.
Using GIT to deploy binary		Commit the war file to GIT repository associated with application Use Git push to deploy	1. Take full advantage of OpenShift GIT application deployment lifecycle 2. Rollback support 3. Deployment to scaled application supported out of the box	1. Some traces of GIT in development lifecycle 2. Extra overhead of cloning and committing binary artifact in GIT repository 3. Overhead in automating and maintaining this process

Binary deployment to OpenShift Using GIT

This post is third post in series of post related to OpenShift binary deployment. Part 1 and Part 2 are available.This is third and final part.

There are two ways to use GIT with OpenShift. Even when an external GIT repository is provided OpenShift creates one for the application and initializes it with external GIT. This is same as creating a local GIT repository and cloning it with a remote GIT repository.

Use GIT repository created by OpenShift

1.       Create an application on OpenShift and select either the Tomcat 7 (JBoss EWS 2.0) cartridges.

2.       Use the git clone command to download the source code for your application to your computer.

                                       i.      $ git clone ssh://533bfd814382ec1fcf00015e@externalgit-everest.punin.sen.symantec.com/~/git/externalgit.git/

3.       Remove the src directory and the pom.xml file from your application that you cloned to your computer.

4.       Place any WAR files that you want to deploy on your gear inside of the webapps directory.

5.       Do $ git add –all your new files, then do a $ git commit -am "committing war file" to make sure that your changes are committed

6.       $ git push to push the changes to gear

Pros:

1.       We will take full advantage of OpenShift GIT application deployment lifecycle

2.       No source code in GIT, only deployable binary file

3.       Rollback support

4.       Deployment to scaled application supported out of the box

Cons:

1.       Some traces of GIT in development lifecycle

2.       Extra overhead of cloning and committing binary artifact in GIT repository

3.       Overhead in automating and maintaining this process

Use external GIT repository

1.       Create a GIT repository

$ git init project01

2.       Add following structure to it

.openshift/markers/java7

This marker file will tell OpenShift gear to use Java 7 runtime. If this file is not present gear will use Java 6 by default.

Additionally you can add following folders. This is optional.

.openshift/action_hooks/ - this will be used to write any pre, post or build hooks

.openshift/cron -  define cron jobs to be run on application gears

.openshift/config – this will contain tomcat config files. In case of custom tomcat settings these will be used.

3.       Create application with external GIT repository

$ rhc create-app --app externalGit --from-code https://github.com/rajeevbadgujar/project01.git --type jbossews-2.0

This will create a GIT repository for the application and clone it with external GIT

4.       Do a $ git clone https://github.com/rajeevbadgujar/project01.git to get a local copy of GIT repository

5.       To be able to commit to the application GIT repository, we have to add it as remote to local GIT repository

$ git remote add openshift -f

6.       Copy the war file to /webapps

7.       Do $ git add –all

8.       Commit war file to GIT repository

$ git commit –am “committing war file”

9.       To push changes to OpenShift GIT repository

$ git push openshift HEAD

10.   This will trigger the OpenShift deploy hook and war file is deployed and activated

Pros:

              Virtually no extra pros other than mentioned in previous approach

Cons:

1.       Extra overhead of maintain external GIT repository and syncing it with OpenShift GIT repository

These are various ways of deploying binary artifacts to OpenShift. 

In the next post I will summarize pros and cons of the approaches we discussed.

 

Binary deployment to OpenShift Using rsync

This is second post of the series- Binary deployments to OpenShift. Please visit
http://technology-edge.blogspot.in/2014/04/binary-deployment-to-openshift.html for the previous post.

Today we will see one more way of binary deployment to OpenShift. The application taken here is jbossews application.

OpenShift build and deployment mechanism internally uses rsync to sync gears with source code and built binary artifacts. When a new Gear is to be added for an auto- scaled application,
1. A new Gears is allocated and the source code i.e. Git repository is copied to new Gear using rsync. 2. Then the build is triggered on the new Gear.
3. When build completes, if Jenkins is used for build then the binary artifacts are copied to another Gear. If Jenkins is not used, this Gear is added directly to HAProxy routing configuration.

The same way can be used by application developers to quickly deploy the built artifacts to OpenShift gears externally. This is useful in case build process is externalized to the OpenShift environment.

Following is the command :-

rsync -avz 533a5c07ac9410a68b00073d@testproject-.:~/jbossews/webapps/

This command will replace the existing artifacts deployed at /jbossews/webapps with the one specified in the command. 

Though this is the simplest approach to deploy binary artifacts to OpenShift there are limitations to this.

1. One will not be able to leverage the OpenShift build lifecycle i.e. various application hooks provided by OpenShift to accomplish certain things before and after the application is build and deployed.

2. The rsync directly replaces the already deployed artifacts so there is no rollback supported.

3. This approach directly pushes the binary artifact to specific Gear whereas an scaled application is deployed across Gears. So this approach does not provide straight forward way of deployment for scaled applications.