Step 1: Pull upstream changes​

git pull --rebase upstream master

The --rebase option places your changes on top of the latest commit without merges.

Step 2: (Optional) Merge your commits into 1 commit​

git reset --soft upstream/master

This command will "undo" all your commits, but won't change the files. So you can commit all your changes in a single commit.

git commit -a

Step 3: Check & test your changes​

To show the changes use a GUI like the built-in gitk, Sourcetree, TortoiseGit or Tower (paid), etc.

Step 4: Push​

git push will throw an error, push with "-f"

git push -f origin master

Additional information​

The command to add a remote is:

git remote add upstream git://github.com/[username]/[project].git

You can also also pull from a direct URL:

git pull --rebase git://github.com/[username]/[project].git

But then you'll need the hash of the latest upstream commit instead of "upstream/master" in the other steps.

1. When Everything Seems too Easy​

My first impression when I first hands on a RPA Tool, everything seems so easy because of the drag and drop features, pre-built functions, puzzle like building blocks that allow you to construct a sequence of actions just at your fingertips. The creator of these tools made it so easy to implement and deploy automation, this causes a lot of headaches and technical debts down the road if we do not do our homework to have a full understanding of what we are trying to automate and what control are needed in-place.

2. Rush into RPA​

Due to the hype related to RPA technologies. When we first started to adopt RPA in our company oftentimes we made a huge mistake calculating ROI by just using 'Current Time Spent' minus 'Future Time Spent' without really think and consider about infrastructure and cost of maintenance. This often due to our team rushing to build up momentum, wanted to prove the capabilities of the tool and most importantly to get buy in from upper management. But realistically most of the current processes is not ready, ended up the team is spending more time maintaining the bot than the manual process.

3. No everyone can do it well​

Too naive to think that everyone can use the tool that have been offered. Business user often been asked to attend RPA course and started to automate some of their task. Unfortunately, most of these automation developed were not properly tested, and assume everything is been taken care automatically. We normally started off working on the "Happy Path" without considering the scenario that are usually more complicated than that. These could be variant of an input or the input can be in a different format that you expect. RPA can complete your job 10x faster, but also can create mistake 10x faster.

4. Just focus on building and Robots are ready, set and forget​

From day one of deploying our first bot, not a single bot can be set and forget. Bot needed to be manage operationally and maintained. We have made mistakes for not properly documenting and communicating automated process with business SMEs. When a bot breaks, no-one will know how to recover the process and leads to unnecessary over-time to figure what had happen and what needed to be done.

On the other hand, due to rapidly changes in business requirements, system upgrade and process changes have causes us lots of bot down-time. Getting involvement of IT and Business SMEs and knowing these changes before hand could reduce unnecessary over-time trying to fire fight to get your bot up and running again.

5. Failing to Scale, not building for scalability​

After 3 years of RPA experience. Started to feel the impact of not building for scalability. Most of our solutions were built in silo mode rather than enterprise-wide. We are much now spending a lot of time re-visiting our solution, re-designing our bots.

Another mistake which was choosing the right candidate processes for RPA, we had wrong thinking about using automation as a quick fix which now end up deploying multiple bots which are doing similar job while ideally they could be designed as a single bot.

Thanks to Heroku, now I have my personal site :)

Too bad, heroku no longer offer free dyno..

If an app has a free web dyno, and that dyno receives no web traffic in a 30-minute period, it will sleep.

Every Heroku account is allocated a pool of free dyno hours, which can be used by Personal apps - apps that are not part of a Heroku Team or Enterprise Team.

If you want to know more about free dyno hours, visit official site here

Method - Cron-job

I am using a free tier account and I don't want my visitor to wait for dyno to re-launch everytime when they visit the site. This is the method I used for keeping my site alive.

• Signup on https://cron-job.org/en/
• Once the signup is completed, verify your email.
• Once you log in successfully, click on the Cronjobs tab. And click on “Create cronjob”.

• Now you can fill in the details. Make sure you enter URL according to your GET method. If your GET method was for route “/home,” make sure your URL is https://your-app.herokuapp.com/home.

If you are not verifying Heroku app with your credit card, you might want to go for user-defined schedule.

• When you reach the Schedule section, click on the option User-defined. Now make sure you select all the values in the columns Days of Month Days of Week, and Months.
• In the Hours column, select all values except for any seven. I selected all values except for 0,1,2,3,4,5,6, which means my app will be asleep from 12 a.m. to 7 a.m. (no job at 6 a.m. means the app will be asleep at 6 a.m.). This step is essential as it satisfies the restriction for the free tier.
• In the Minutes column, select only 0 and 30 because your app will only sleep every 30 minutes.

This is how your schedule settings will look in the end. Once everything looks fine, create your cron job.

The last picture is with the normal settings

User Defined Settings​

Normal Settings​

Congratulations! You have successfully kept your Heroku app alive.

BlockPublicAcls - This prevents any new ACLs to be created or existing ACLs being modified which enable public access to the object. With this alone existing ACLs will not be affected.

IgnorePublicAcls - Any ACLs actions that exist with public access will be ignored, this does not prevent them being created but prevents their effects.

BlockPublicPolicy - This prevents a bucket policy containing public actions from being created or modified on an S3 bucket, the bucket itself will still allow the existing policy.

RestrictPublicBuckets - This will prevent non AWS services or authorized users (such as an IAM user or role) from being able to publicly access objects in the bucket.

Turn OFF HDMI output

sudo /opt/vc/bin/tvservice -o

Turn ON HDMI output

sudo /opt/vc/bin/tvservice -p

Turn OFF USB chip

echo '1-1' |sudo tee /sys/bus/usb/drivers/usb/unbind

Turn ON USB chip

echo '1-1' |sudo tee /sys/bus/usb/drivers/usb/bind