For me, there have been two items in “Atomic Habits” that have immediately made a difference in my life.
The first is in Chapter 6, under the heading “The Context Is The Cue”, the understanding and the realisations following my reading that our habits can be associated not with just one single ‘trigger’ but with the ‘context’ that surrounds a behaviour, have changed my day to day actions.
The second is in Chapter 7, on how ‘disciplined’ people structure their lives in such a way that they do not require huge amounts of willpower and self-control; has caused me to change a number of small things, and this has made a large impact for me.
Implementing these two things into my life have not required any ‘rocket science’ on my part, just some simple changes. Those simple changes have made an immediate, positive difference in my life.
James explanation of these two things, the examples he uses, have made sense of why, in the past, some habits have stuck for me, why others haven’t, and why certain habits I’ve tried to change or remove haven’t changed or been removed.
PS. rest of the book is great, but those two things are what made the difference for me.
It lets multiple developers, programers and project managers all work on the source code for a project with minimal stepping on each others toes. The workflow we use is as follows.
We keep the a Git repository in the cloud, typically in Bitbucket.
Each developer then keeps a local copy of the repository. The developer can then create a new feature branch to work on an issue. More than one developer can work on a project at a time, and multiple branches can co-exist at the same time. This allows for more concurrent effort to be deployed.
(This image from the git-guide linked below)
Typically then the QA will pull that feature branch to a test server and test the new feature/issue for completeness/quality.
If they are happy with the quality of work, they can then merge that feature/issue branch into the master branch.
Then on the production server we can pull the master branch and deploy it in production.
We link the bitbucket repository with JIRA and Confluence so that features, issues and bugs can be more easily tracked and discussed.
For more information on how to use git, see the git-guide.
Using the cases.date_modified is not the same as the date a case is closed, as the case may have been modified after it was closed.
Thus, the query below will return the date the case was transitioned to ‘Closed’ provided the cases.status field is being audited.
CONVERT_TZ(cases_audit.date_created,'+00:00','+10:00') as 'date_closed',
accounts.name as 'account',
cases.name as 'case_id'
join cases on cases.id = cases_audit.parent_id
join accounts on accounts.id = cases.account_id
cases_audit.field_name = "status"
and cases_audit.after_value_string = "Closed"
Note, you might get more then one row returned per case if the case was re-opened, also my code above assumes a timezone of UTC+10
His Applescript does a fantastic job of this, the only issue I had was that my iCloud account was named differently to ‘iCloud’, all I did to resolve that was to rename my account in Apple Preferences > Accounts back to iCloud while I did the export.
A great deal of psychological research shows that studying in a burst is less effective than study sessions spaced out over time. Blogs naturally embody the latter method, dripping out ideas over weeks and months instead of in a burst.
I commute to work every day on my motorcycle, it’s a 52 kilometre trip each way. Wearing my headphones, Waze lets me know of any accidents or hazards ahead but because the phone is in my jacket pocket, I only hear such warnings, I don’t see them. It would be nice to see the Waze screen.
I was talking with the folks over at MobileZap, who said I should try out a Olixar Universal Bike Phone Mount on the bike. So for the last month I’ve been quite happily riding around, able to see the screen with an easy glance. An added side benefit is that when I’ve received a phone call, I can see who it is and decide if I’ll pull over and talk or not. Previously I’d just ignore all phone calls whilst riding.
The holder itself I thought looked a bit flimsy, however it has held up really well while I’ve ridden through both really hot days (34°C) and heavy rain.
After placing the phone between the two grippy holders, simply squeeze them together and the phone is securely held. I’m using an iPhone 6 in an Otterbox Defender case and it accommodates the larger case quite well. There is a small fold-out piece at the bottom if you’re worried about it falling out the bottom, but I’ve found I don’t need it, the phone doesn’t slip or move while in the holder at all.
To release the phone, there is a small button on the lower right hand side, pressing it causes the two holders to release their grip. Although I was concerned initially that it wouldn’t hold my phone securely, it turns out that it does hold it really well, I’m now quite confident that the phone won’t come loose and fall out while I’m riding.
If you’re looking for a phone holder to fit to your road bike, I can happily recommend this one.
Thanks to MobileZap for providing this product for me to test out.
I’ve had a client whose Linux Server (CentOS) gradually gets slower and slower, then falls over.
By logging into the MySQL command line, we were able to see that there were some long running queries that never end.
| Id | User | Host | db | Command | Time | State | Info |
| 2322386 | ssgadmin | 10.21.1.149:58526 | sugarcrm_ssg | Query | 2202 | Sending data | SELECT IFNULL(hr_humanresources.last_name,’’) hr_humanresources_last_name ,l3_cstm.verification_c l3 |
The key part here is that hr_humanresources_last_name has an underscore between the table name when it should be a period i.e. hr_humanresources.last_name. Knowing the table name was enough to tell me it was caused by something to do with SugarCRM that’s running on that server. But we don’t yet know what action caused these queries.
Knowing it was 2202 seconds ago from the time we ran the query we are able to pinpoint a time the action occurred. Looking through the SugarCRM log files did turn up that the error was often caused by a single user, but didn’t show up anything to help us figure out exactly what was the causal issue. Talking with that user, getting them to do what they’d done at that time didn’t turn up anything, the error wasn’t reproducing on demand.
So I turned to looking in the tracker table in the SugarCRM MySQL database for entries around the time of the error. Turns out that there is a Dashlet being loaded, that Dashlet uses a Report.
Each time I load the Dashlet or run the Report I get a corresponding long running query turn up. We’ve found our culprit, and we’re now able to recreate the report.