I often see people who seek self improvement come up with a resolution that consists of a scary list of boundary pushing commitments. Something along the lines of "Starting tomorrow, every day I'll wake up every day at 5 am, jog 10 kms, study 2 hours and clean a room in my apartment". This is not even a hyperbole.
There are a bunch of things that will make this type of resolution an almost guaranteed fail. One of them I've already touched before, the concept of adopting one habit at a time.
This time I want to touch on another, which is committing to more than you can chew.
As habits and personal commitments build up it becomes increasingly difficult to fit in new ones. Despite our best efforts, some commitments that we know are good for us can fail to become automatic habits that require no willpower or attention to execute. Yet, since we recognize the importance, we remain committed, at the cost of some willpower and attention.
The mental carrot is a reward I give myself for completing a task. But there are two ways to complete a task: You can either treat it as an obstacle and get it out of the way as soon as possible, or you can treat the task as the center of your existence for the time you're performing it.
Read more »
This subject is extremely close to my heart. I've had a morning routine of some sort for about 2 years now, and I can't imagine how far behind where I am now I'd be without one.
In a sentence, a morning routine is a ritual you perform every day, first thing after getting up. Its content and length is entirely personalized, and its goals are to help you kick start your day, and move you towards your goal, steadily and consistently.
Read more »
One of the my favorite strategies towards being productive and undistracted is tunnel visioning on a well defined task and making its completion the focus of my existence. This has been working great to keep my focus on the task at hand and not be tempted by distractions. But once the task is completed, I tend to experience a kind of energy drop that allowed procrastination and laziness to creep in. I knew what my next task is, but having exhausted my attention and energies on completing the current one, I just didn't feel like getting on straight to the next.
What we do is important, otherwise we wouldn't be doing it, right? But sometimes our subconscious is not on board with this, and the goal behind the tunnel visioning technique is to convince every part of your brain that what you're doing IS important. But there's a missing component - if this task is so important to get done, why is your reward for completing it is just.. Another task?
Read more »
I find myself keep needing this, so I'm posting it for my future reference and perhaps yours.
The short of it:
mklink /J [target-folder] [source-folder]
mklink /J C:\Users\Matthew\Desktop\Dropbox C:\Users\Matthew\Documents\Dropbox
While working on a new pet project I ran into an annoying problem with Foundation Zurb 5's top bar dropdown. I couldn't find any solution on the web so I thought I'd share a workaround.
The top bar dropdown is shown and hidden using CSS in a way that prevents the click event propogation. If you want your menu items to do something other than an href, like listening to a click and doing something programmatically, you're out of luck - the event won't fire.
Here's a JSBin with the problem demonstrated:I've added click listeners on the menu items that should open an alert window when clicked. Try clicking on dropdown->link, nothing will happen. This is because the element is hidden before the event can trigger.
I wanted to keep Foundation's hiding CSS because in the comments it is said to support accessibility. I assume there is some learned knowledge sunk into it so I prefer not to touch it directly, but manipulate around it with code.
Therefore I won't call it a solution because it's not elegant enough, but it works and should get you out of the bind if you're in it. I'm using the scss version so I'll describe what I did there. At the bottom of the post I've linked a JSBin with the solution in plain CSS.
Open _top-bar.scss, and find the following snippet:
The @include represents the following CSS:
(plus a display:block)
Move the @include into a new class (give it whatever name you see fit)
Now, in your HTML, add the class to the dropdown. I am using Ember so the following is a Handlebars template:
The unelegant part is that you need to control the dropdown visibility from code. It shouldn't be super dirty; if you listen to clicks on the dropdown and toggle the hiding class it should do most of the trick.
Here's a JSBin with the solution with plain CSS
If you have a nice CSS only solution for this please share in the comments.
The purpose of the technical overview is to present approaches for tackling and solving challenges from start to finish. I am aiming this series for intermediate level developers. This means that I expect the readers to be fairly familiar with programming and some web technologies (i.e. not complete beginners), and I will spend very little time delving into implementation details, so very experienced developers may be familiar with most of the content.
Despite being a blasphemous Windows user, I still love using the git bash. It's way quicker than GUI for many operations, and it allows me to immediately check which branch I'm on. Combined with the knowledge of a few keyboard shortcuts, I can also perform quick operations on multiple repositories in sequence by having several bash instances open. This flexibility is simply unrivaled by GUI.
There are some operations, though, where the power of GUI really shines through. When committing changes, for example, I like to go over every file I changed and go over the changes quickly to make sure there are no stray debugging leftovers, surprise code changes that I didn't expect, or commented out sections that need to be uncommented. I find this habit to be a valuable tool in reducing bugs. Via Bash, it is much harder to quickly scan large amounts of code. Another example where GUI is better is when resolving merge conflicts. Again, the ability to see large amounts of code, in this case side by side, makes Bash the lesser tool when compared to GUI. Finally, viewing the changes log is something I do often; GUIs tend to have log features that the default git log command doesn't support: A graph showing how the branches are connected, changed files for each commit, etc.
Therefore, I came up with a few shortcuts that trigger the GUI from Bash, winning me both the flexibility of command line and the ease of use of large graphical screens when I need them. In this tip I will be demonstrating with the TortoiseGit GUI, but the same principle can apply to any GUI that offers command line arguments.