April 23, 2018

Simple way to check if CRON is working!

Recently, we moved from hosting our app on Amazon EC2 instances to Elastic Beanstalk Service. For those who had a go at hosting their apps on Elastic Beanstalk, you would know the struggles with .ebextensions. There are far more documentation and examples available now than when it was first released into the market. One of the most challenging things to do in Beanstalk is running Cron. The recommended way of doing it is via the creation of worker environment that processes long-running workloads on demand or performs tasks on a schedule. It makes use of other Amazon services like SQS queuing.

This is okay for some people who have genuinely long-running processes but our PHP application was pretty straightforward. Most of the CRON jobs would be completed in seconds. For us, running a separate worker instance with all its resources was pointless and a waste of resources. So we need to come up with another way. The other way of running CRON is using something called “leader_only” declarations in the .ebextension file. By using that, you are asking Beanstalk to run the CRON Jobs only on the first instance. This avoids multiple instances running the same CRON jobs because that would really screw things up.

Anyway, we need to get the YAML right and there is a neat little utility online that lets you validate your files. It’s called YAMLlint.com. Check it out. To see if your CRON is running as it should, here is a neat little way to test it. Obviously, the whole point of using Beanstalk is to avoid having to manually edit code on single instance so it takes away the need to setup FTP or sFTP. I suggest you do set it up for your first instance so you can check if the CRON is running and if everything is deploying as it should. There is no harm done in double checking right 😉

1. Edit your CRONTAB or in Beanstalk’s case, add it to the .ebextension folder.

$ crontab -e

2. Add the following line inside your CRON which basically will append the current date to a log file every minute. The 6 fields of the crontab file are minute, hour, the day of the month, month, the day of the week, and the actual command.

* * * * * /bin/date >> /tmp/cron_output

3. Exit the editor and you should see an output something similar to this.

crontab: installing new crontab

4. Check if the CRON is running every minute as it should through running this command which grabs the output of the file being stored in /tmp directory.

tail -f /tmp/cron_output

You should see something similar to this as the output.

Mon Apr 23 00:01:01 PDT 2018
Mon Apr 23 00:02:01 PDT 2018
Mon Apr 23 00:03:01 PDT 2018
Mon Apr 23 00:04:01 PDT 2018
...

If you don’t see it regularly running every minute, then you know something is not right with the CRON service. If you don’t see the file at all, then you know the CRON is not running. This narrows down things down to what is working and what isn’t. Saves you some hours on figuring out whether its Elastic Beanstalk file playing around or your actual CRON commands or something else. Hope this helps 🙂

I will be writing the way we setup CRON in the future blog post. Watch the space!

February 9, 2018

Restoring Google Authenticator 2-Factor Authentication Codes after iPhone Reset

Google Authenticator Iphone Restore

Recently Apple admitted to purposefully reducing the speed of an iPhone to conserve it’s battery life. In other words, they want people with older iPhones to go for a new one because the old ones seem slow and sluggish. As you would imagine, people didn’t take this in very well. There were tons of supporting and opposing articles around Apple’s decision to do this. Anyway, I have an older iPhone 6 Plus model and didn’t feel the need to upgrade (as of yet). And yes, it was slow and sluggish, so I decided to get my battery replaced hoping it would fix the problem. To my surprise, the wait time for a battery replacement of iPhone 6 Plus model was surprisingly long – close to 3 WHOLE months.

I couldn’t wait that long so I called up Apple and the nice guy on the phone ended up replacing my iPhone with a brand new one. He did charge me an out-of-warranty replacement fee but I was okay with that. The recommended procedure for moving your old phone’s data to the new phone is to use the iTunes back up and restore feature. I followed that and all the apps seem to be functioning the way they did.

If you have a lot of apps like I do, it does take quite a bit of time. You have to tap on each app for it to load as they get stuck sometimes. After the restore, it wasn’t amazingly fast but good enough to run the show. The only app that didn’t restore as it should be was the Google Authenticator app which is used for two-factor authentication. So heads up to all the developers out there moving their data to newer phones, Google Authenticator two-factor authentication codes would not be restored.

So you got two options…

  1. Log in to each of the sites you use 2FA on and switch off the 2FA
  2. If you have backup codes, you can reinstall Google 2FA and subsequent codes for each of the sites

Ps. To all the peeps wanting to get an iPhone 10/x, there are rumors that Apple would be releasing a plus version next year. I might or might not be waiting for that 😉

December 4, 2017

Deleting Magento Customer Address Programmatically

When upgrading Magento for one of our customers, we’ve realized somehow all the shipping information were half complete. It either had a region filled out without address or zip code. When you enter that customer’s profile and try to save it, it wouldn’t save because these are required fields. This was causing these old customers to purchase stuff from the store because they assumed their address was saved.

The best thing to do when you encounter such an issue with Magento is to clear saved addresses altogether. Our team has written a neat little script that would delete all the saved addresses given that you know their email addresses. This is easy to find out if you were to just export all customer profiles through Magento panel. Some might argue that you can do this Data Profiles Import/Export function. Unfortunately, Magento has a function to replace only if the value contains something. If you leave it blank, it wouldn’t touch that field. So you would still have the customers whose addresses are half filled with missing information.

I hope this helps someone in need 🙂

<?php
  include('app/Mage.php');
  Mage::app();  
  
  $customer_emails = array(
    "user1@example.com",
    "user2@example.com"
);
  
  foreach($customer_emails as $customer_email){
    
    echo $customer_email . "</br>";
    $customer = Mage::getModel("customer/customer");
    $customer->setWebsiteId(Mage::app()->getWebsite()->getId());
    $customer->loadByEmail($customer_email); //load customer by email id
    $customer_id = $customer->getId();
    
      echo $customer_id. "</br>";
      foreach ($customer->getAddresses() as $address)
      {
         $customerAddress[] = $address->toArray();
         
         $address->delete();
      }
      
    echo '<pre/>';print_r($customerAddress );
  }
  
  
?>

 

October 11, 2017

Get rid of .DS_Store files from GIT Repo on Mac OS X

Whether you are new to GIT repositories or an experienced developer, I am sure, at some point in using GIT, you must have come across these annoying .DS_Store files that seem to populate out of nowhere. It is a much apparent problem if you have enabled viewing hidden files.

What are they? DS_Store is a short form for Desktop Service Store that contains attributes of a folder and is created every single time a folder is navigated to. The more you navigate through your program source code, the more .DS_Store files you will end up finding. You can delete them but they will appear again.

I am okay with seeing them on my Mac but when you have an auto deployment script setup for GIT, you prefer not having these useless files on your Linux machine. We use a neat little auto deployment script which gets executed each time new updates are pushed to our repository. We have a repo for each of our business applications so it saves our developers plenty of time navigating their way through FTP programs and updating files through that.

To help address this issue, you can configure GIT globally to ignore .DS_Store files by executing this the following:

git config --global core.excludesfile ~/.gitignore

OR, if you already pushed some of these .DS_Store files, you can get rid of them from your repo in the following way. Go to the root of your app directory and execute the following command in terminal:

find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

That will get rid of all recognition of .DS_Store in your repo. Next, add the .DS_Store to the ignore list. You can do that by simply creating a .gitignore file. Place the following in the .gitignore file at the root of your app directory.

.DS_Store

Save it as .gitignore and push the changes through. Voila! One less annoying problem to worry about 🙂 I am still giving thought towards publishing the source code for our Auto Deploy script 😉

Newer Posts
Older Posts