Looking for just the right Focus Timer: For breaks

The Pomodoro Technique is a well known and widely used way of training your mind to focus on the task at hand. Lately, I’m using it more and more as a way of taking better breaks. Without a timer, I find myself continuing to work on a problem for far too long without stepping away to recalibrate my thinking. When stuck in gear, I spin my wheels rather than reapproaching a problem such as how to update an Eloquent query or change how to calculate metrics in an array.

At times, coding is about building a known structure but many times critical thinking is essential to figuring out that annoying bug your seeing. Breaks are important for good habits! 

The goal is to find just the right timer. The criteria is:

  1. All the standard features must be there with adjustable intervals, goals for the day, so on.
  2. Organization of the timers with the ability to add names or categorize them.
  3. Available on multiple devices, mostly iOS and Mac but Windows would be helpful.
  4. Team availability and pricing are less important but definitely factor in.
  5. More on the nice to have but syncing between devices.
  6. Also nice to have is a sync to other services, Harvest or other time tracking apps.

Currently, I’ve been using the BeFocused app for iPhone and Pomodoro+ for Mac in my daily habits and both have their merits but I’m not quite satisfied, which is what prompted this search. The first update will be on these 2 and an overview of all the timers found.

Why use SQLite with Laravel

At first, it wasn’t immediately obvious why to use SQLite, over MySQL, with Laravel but a couple good cases have come up.

  1. For AnimaticBuilder, since a robust user database setup isn’t needed just yet, SQLite works great since it’s fast, portable, and easily versioned. Even later, when a user database is needed, individual SQLite databases could be used for sequences.
  2. On Laracasts, folks have pointed out how to use the SQLite as the database for test cases, https://laracasts.com/discuss/channels/testing/how-to-specify-a-testing-database-in-laravel-5. Here too, the database can continue to be used as a test bed through the development of an app. (Just make sure nothing secure gets saved there.)

WordPress 4.4 Sidebar Naming

With WordPress 4.4 rolling out a few issues have come up around sidebars and widgets but one fix is not immediately obvious. When adding a sidebar, the naming previously was not case sensitive but it is now. The example below would not work:

 register_sidebar(array(
 'name'=>'Homepage Widget',
 'description' => 'Main Area on the Homepage',
 'id' => 'homepage',
 'before_widget' => '',
 'after_widget' => '',
 ));
<?php if (!dynamic_sidebar('HomePage')) : ?>
<?php endif; ?>

Now, make sure that the sidebar call uses the exact ID.

<?php if (!dynamic_sidebar('homepage')) : ?>
<?php endif; ?>

Want to learn Laravel? Tear apart Illuminate

There are any number of ways to learn Laravel. From the documentation right on laravel.com to the very complete tutorials over at Laracasts.com but there is also great way to learn the basics bundled in the install. Navigate to /vendors/laravel/src/framework/illuminate and dig into the modules that form the key functionality included in the original configuration.

Each one of these modules is registered in the app/config and, since Laravel 5, they now reside in the vendors directory leaving the app directory fairly spartan. Spartan is good but figuring out how the original functionality by looking through that directory is a bit tricky.

The vendors directory holds all packages added to the base install as well as holding the core packages in /vendors/laravel/src/framework/illuminate. By opening up /illuminate you can look through, and learn from, a number of packages including:

  1. Hashing, great for learning simple service provider setup.
  2. View, which has some pieces in the app directory as well and covers middleware.
  3. Authentication was added as core functionality and has a number of working parts good to explore.

 

Laravel and JQuery: Don’t Abuse GET

jQuery and Laravel are amazing libraries and frameworks but they don’t always inspire the best practices. Recently when building a basic app I made a fairly amateurish error without even realizing it at first. In building a simple Create/Edit route I used the Route::resource as a shortcut and for making AJAX requests to the route I used $.ajax() on page. The requests work great and everything seems to working fine until sending a large request and right then I realize $.ajax() is using a GET request rather than POST. There are a couple lessons here, you should have XHR requests properly outputting to console.log() so you see what your AJAX requests are doing. But more than that don’t expect jQuery and Laravel to do all the lifting through their syntactic shortcuts. At times, being more verbose with your code can avoid some nasty mistakes.

Explaining your Resource route with a couple ::get or ::post routes looks messy but actually can help to both avoid errors and aid in development by being more obvious to understand quickly.

As well, $.ajax() in jQuery is an all purpose request and specifying your Type can save headaches and keep requests from falling into the wrong lane.

Stack jQuery events on elements to avoid delays.

While building a bit of code for phlodl.com jQuery was acting up when adding a simple mouseover to expand and the event was delayed when the mouse entered the element. To fix this I daisy-chained the events on the element to fix the delays:

Delayed animation:

$('.feature').mouseenter( function() {
$(this).animate({
height: 540
}, 'fast', function() {});
});

$('.feature').mouseleave( function() {
$(this).animate({
height: 300
}, 'fast', function() {});
});

Seamless:

$('.feature').mouseenter( function() {
$(this).animate({
height: 540
}, 'fast', function() {});
}).mouseleave( function() {
$(this).animate({
height: 300
}, 'fast', function() {});
});