Opening iTerm2 Tabs at Specific Directories

I love iTerm2. I can customize the stock Terminal.app just about as much, but it's much easier in iTerm. I find myself always opening the same 3 or 4 tabs when I get into coding mode. Luckily iTerm2 has great scripting support

The 4 tabs I always open for Kidfund are:

  1. Our iOS project
  2. Our Laravel project. Usually where I run artisan commands
  3. Our Laravel project; Tails most recent file in the log directory
  4. Our Laravel project; I jump around from here. Usually CD-ing to 1. the realm directory to pop it into Realm Browser

I didn't want this to run all of the time so I didn't have this script run each time iTerm opens. I instead wired it into an Alfred command. If you are interested you can download that here

The underlying script is as follows. It's crud, and could definitely be more flexible, but it works for me at the moment. Hopefully it can help you craft something to your needs

tell application "iTerm2"
  tell current session of current window
    write text "cd ~/workspace/kidfund/ios"
  end tell
  tell current window
    create tab with default profile
      tell current session of current tab
        write text "cd ~/workspace/kidfund/web"
      end tell
  end tell
    tell current window
    create tab with default profile
      tell current session of current tab
        write text "cd ~/workspace/kidfund/web && tail -f storage/logs/\"$(ls -at storage/logs | head -n 1)\""
      end tell
  end tell
    tell current window
    create tab with default profile
      tell current session of current tab
        write text "cd ~/workspace/kidfund/web"
      end tell
  end tell
end tell

Hey Mama! Podcast

We bring our husbands on to discuss #fatherhood, have them share their #igotthis and #idontgotthis moments since becoming dads, and they make recommendations on apps, books and more for soon-to-be or new dads. We tell stories about their early parenting days and as usual, talk about our weeks.

I joined the Hey Mama! podcast for a very special Father's Day episode.

Check it out!

App Launching On Apple Watch

I love using the Stopwatch and Timer apps while I'm cooking or brewing coffee, but I don't want their complications visible during the rest of the day. The ability to swipe left and bring up an entire watch face devoted to them and any other complications relevant to cooking is a game changer for me. I'll keep my existing primary watch face configured with the date, and a few activity / fitness complications, and I'll also have my Movie watch face with no distractions that Ryan Considine inspired me to use.

I hadn't even thought about using different watch faces for different tasks or themes of tasks.

I already switch faces of its the weekend (don't need calendar for example) but this will take it to a whole new level

Github File and Link Tricks

2 tricks I learned today that I'd like to share: reliably linking to a specific line and searching for files using fuzzy matching.

Reliably link to a specific line

Say you are on the master branch, and you want to reference a line in a file. This could either be for a conversation you are having at that moment, answering a question in a PR, or adding information to a ticket. At that point in time, your link will work great. But, what about when that file gets changed tomorrow? More lines get added higher up, above the link, and the line that the link it pointing to, now points to something else!

You can easily have github switch to the latest commit for the file you are viewing. Just press 'y'. Then, when you link to a line, you are linking to THAT version of the file. You reference will always be intact.

Search for files using fuzzy matching

When you are browsing through files, there is a button in the upper right that says "Find file". I'm sure it's been there forever, but I just noticed it.

This brings you to a full file tree that you can search using fuzzy matching. Just like if you were in your IDE quick-opening a file!

Avoiding Blackberry’S Fate – Marco.Org

The BlackBerry’s success came to an end not because RIM started releasing worse smartphones, but because the new job of the smartphone shifted almost entirely outside of their capabilities, and it was too late to catch u

Today, Amazon, Facebook, and Google are placing large bets on advanced AI, ubiquitous assistants, and voice interfaces, hoping that these will become the next thing that our devices are for.

If they’re right — and that’s a big “if” — I’m worried for Apple.

Marco makes a lot of good points and I agree with this 100%. The mobile phone market as we know it is primed for the "next big thing" by someone. Who that is, and whether they are right remains to be seen. Do I mean that the current market is stagnant, or that innovation is dead? Of course not. But, I do think changes we'll see from the big 2 to their platforms will be incremental. There will always be new UI paradigms, features, and apps that can augment a platform.

The next large improvement will be what our devices start DOING with the data we give them. Not just inputs and outputs. But contextually understanding the data and begin to make predictions on it. Apple is "good" at the former; give them something and they will give it back to you quickly. iMessage and the new photos are examples of this. Passwords, backups, and sync are examples of where they fall short. However, they can't act on that data. Photos knows who someone is because you tagged them. Or knows how much you liked a photo or a restaurant because you gave it stars. Input and outputs. Compare this to Google photos (which is downright amazing) that automatically just "knows" who is in the photo or figures out that an event took place because you traveled to it.

Google is king of data mining and context (Facebook and Amazon are not far behind). As Marco explains in his piece, Apple just can't catch up to that. It's my hope that the awesome that Google will bring in the form of Ai to devices won't be restricted to Android. I'm sure that Android will always have the most seamless experience, but it will be nice if Google's apps bring much of it to iPhone. Even better, would be for Google and Apple to get along again ala when Google Maps came installed on your iPhone

Setup and Teardown the Database Once Per Test Suite in PHPUnit

I'm working on a series of integration tests where I want to set up and reset the database for each run. This could easily be done in the setUp and tearDown methods, but doing the full db each time is slow. Yes, I could just do the tables I need, but I was curious, and now I don't have to worry about which tables are setup in my testing DB. In this example, I'm using Laravel's migrations and SQLite as the test DB.

UPDATE 05/05/2016: As Sebastian points out below (thanks!) there is a much more appropriate way. Using setUpBeforeClass and tearDownAfterClass we achieve the same effect

public static function setUpBeforeClass()
{
    parent::setUpBeforeClass();
    exec('php artisan migrate --database sqlite_test');
}

public static function tearDownAfterClass()
{
    exec('php artisan migrate:reset --database sqlite_test');
    parent::tearDownAfterClass(); 
}

PHPUnit has listeners that you can tap into at various parts of your tests' lifecycle. I'm particularly interested in when a specific suite starts and ends. We'll need to do 2 things:

  1. Create our Listener
  2. Register this Listener in phpunit.xml

The listener is as follows:

class FullDBListener extends PHPUnit_Framework_BaseTestListener
{
    protected $suites = ['UserIntegrationTest', 'AccountIntegrationTest'];

    public function startTestSuite(PHPUnit_Framework_TestSuite $suite)
    {
        if (in_array($suite->getName(), $this->suites)) {
            exec('php artisan migrate --database sqlite_test');
        }
    }

    public function endTestSuite(PHPUnit_Framework_TestSuite $suite)
    {
        if (in_array($suite->getName(), $this->suites)) {
            exec('php artisan migrate:reset --database sqlite_test');
        }
    }
}

This does a few things:

  1. Stores the class names of each suite we want to run the db migrations for
  2. In startTestSuite it checks to see if we're in the right suite
  3. If we are, run an artisan migration on our test db
  4. In endTestSuite it checks to see if we're in the right suite
  5. If we are, run an artisan migration:reset on our test db

Next, we need to make PHPUnit aware of this listener. Update your path accordingly

<listeners>
    <listener class="FullDBListener" file="./tests/app/FullDBListener.php"></listener>
</listeners>

That's it!

I do do some basic teardown in my test suite's setUp method to give me a blank slate. This has proven faster then doing the migrations each time

public function setUp()
{
    parent::setUp();

    User::truncate();
}

I hope this helped you, if you have any questions, let me know!