The Alfa Romeo Giulia is, in some ways, a moonshot by Alfa Romeo. For Americans, we haven’t seen an Alfa Romeo sedan in a very long time. The Alfa Romeos that we have seen have been coupes or convertibles, and they have been very rare. The Giulia—and the Stelvio—are Alfa Romeo’s attempts to recapture the American market.

Thanks to a friend, I was able to get seat time for a week in a 2017 Alfa Romeo Giulia Quadrifoglio. The experience of getting a press car is likely going to be a blog post in and of itself, but for today, I want to talk about the car.

Video

If you’d like to hear and see me talk about the car, please check out my first car review video on YouTube:

This is my first effort at doing, well, anything like this. The video has some areas for improvement, but I’m proud of it. I hope it comes across as a great starting point for something big, because that’s what I think it is.

If you’d like to give me feedback about the video, please contact me.

What is this?

The Giulia, in general, is in many ways a competitor to my current car: the BMW 3-series. Though it felt a bit larger than my E90, it definitely felt as though it was in the same segment. Interestingly, much like the 3-series, the Giulia has quite a broad reach. The “beater” model is $38k, which is aspirational but attainable for many people. The range continues all the way up to the car I tested, the Quadrifoglio, which starts at almost $75k.

The car I drove is in many ways a BMW M3 competitor. An M3 competitor with a 500+ HP twin-turbo V6 that is—by all reports—sourced from the Ferrari California. In many ways, the Giulia Quadrifoglio is not shy about the notion that it’s chasing, and possibly catching, the M3.

The Inside

So much of the Giulia felt eerily familiar to me. As has been said, great artists steal, and Italy is nothing if not a country of great artists. In this case, the interior designer clearly stole from BMW. To my admittedly biased eyes, that’s a great place to steal from.

The infotainment was a knockoff of BMW’s iDrive. It wasn’t as nice, nor as intuitive, but it was nice enough and intuitive enough to keep me from getting infuriated. In fact, the only thing that really drove me bananas was being compelled to manually re-enter Bluetooth audio mode (to listen to audio from my iPhone) every time the car was started.

Otherwise, the interior was nice. The build quality felt great and easily on par with its German neighbors. Switchgear felt great and was obviously located.

There was some Italian flair, of course. The steering wheel is flat-bottomed. The start/stop button is on the wheel, rather than on the console. The turn signals would return to center—much like BMW—but could only be canceled by pushing the opposite direction. (My car lets you cancel by re-engaging the signal in either direction.) Even at the end of the week, it infuriated me.

Nevertheless, cars aren’t really about their interior, and the Quadrifoglio is definitely not. It’s about being on the road.

The Drive

Driving the Giulia was an interesting experience, because it was driving three four different cars all at once. The Quadrifoglio has a drive mode selector—as most cars of this caliber—that carries the cutsey labels of DNA:

• Dynamic
  Sporty but still approachable
• Natural
  Normal/balanced driving
• Advanced Efficiency
  In case you’re feeling frugal in your twin-turbo V6

Additionally, there is a fourth mode available:

• Race
  Hold onto your butts

When Race mode is engaged, the exhaust gets louder, and has a different pitch. Stability control is turned off. Traction control is turned off. The car is 100% raw, and is 130% ready to murder you. There is no way to turn traction nor stability control back on. When you’re in Race mode, there is no turning back.

One thing I wished so badly was for the car to have the ability to use the Race mode exhaust, throttle response, engine timing, and everything else, but not disable traction nor stability control. I know my skills, and they left me wanting. I need a parachute.

However, the Quadrifoglio in full attack mode is vicious. The shifts are nearly instant, and the response is too instant for a forced induction car, unless you’re really low in the rev range. Whenever I hit redline, the car felt like it had much more to give. It was champing at the bit, begging for more.

500+ HP will do that to you.

Furthermore, despite the car having one of the much-maligned electric power steering systems, I actually couldn’t tell. During the time I had the Giulia, before I looked up what kind of power steering it used, I wasn’t sure by feel alone if it was hydraulic or electric. Thinking about it, that’s about the biggest compliment I can pay the steering.

But let’s take a step back:

The shifts are nearly instant

Why… why are the shifts something that’s happening to me? Are you telling me this car isn’t a three-pedal car‽

The ZF 8-speed

This car absolutely has an Achilles heel, and it is the transmission.

Or does it?

I’ve been a devout driver of standard transmission cars for my entire life. I don’t want to buy anything else, ever. I hate relinquishing the control of the car to a computer. I want to be the one that decides when to shift. I want to be the one that is challenged to shift effectively, quickly, and smoothly. I want it to be all about me.

The Giulia is powered by a ZF 8-speed automatic transmission. Not a dual clutch, but a true, torque-converter-included, automatic.

Stop the review, I’m out.

Except, maybe not.

I had heard many, many times in the past that the ZF 8-speed, used in many modern BMWs among others, is really good. Like, really good. I remained skeptical, though. Give me a clutch pedal—even a computer-operated one—or give me death.

After a week with the Giulia, I’m not so sure I was right.

The Giulia Quadrifoglio is a stunningly, stunningly fun car to drive. And though I occasionally missed rowing my own, often times, just wrenching back on the + paddle gave me nearly the exact same feeling. Sure, there are few things in the world that can match a perfect, heel-toe, rev-matched downshift. But holy hell, hearing and feeling this thing rip through the gears, pulling on the paddles like the leash on a rabid dog, was amazing fun.

Which gave me pause.

Second Thoughts

My entire life, I’ve defined myself in many ways, not the least of which is my preference insistence on driving a manual transmission. I sneered at all the old mustachioed men in their automatic Corvettes, buying a car that was ostensibly about performance, but in reality about showing off. I snickered every time I saw a DCT M3 outside of the track, attributing the choice to laziness or ineptitude rather than performance.

Now, I’m not sure what to think.

I had so much fun in the Quadrifoglio. More fun than I ever expected. To be sure, I expected to have quite a lot of fun. But as it turns out, a properly tuned automatic, which favors locking itself up as often as possible, can get me 80% or 90% of the way to perfection. In fact, it can make me happy in ways a stick can’t, particularly in traffic.

The Giulia Quadrifoglio made me rethink what I thought about transmissions.

What I thought about cars.

What I thought, and think, about myself.

Which is a hell of a lot to get out of a week with a hunk of metal.

The wonderful organization, App Camp for Girls, has been interviewing various people in the field as part of their “Fireside Chat” series. My interview was just posted, and I’m happy with how it turned out.

There’s a ton of great interviews; be prepared to lose a couple hours to all of them.

Also worth noting, App Camp for Girls is currently raising money to expand to three more cities by 2020. App Camp’s mission is to promote gender equality in technology, which is something everyone should be able to throw their weight (and money) behind.

If you have even a dollar to spare, please support AC4G. I have.

Though I haven’t talked about it here on the blog, I was lucky enough to get a week of seat time in a really nice car. That seat time was arranged by Sam Abuelsamid of Wheel Bearings.

When we set out to do Neutral, what we hoped to be creating was what Wheel Bearings actually is. Informed hosts, with diverse opinions, talking about all things automotive. Between Sam and Dan Roth, there is not only tremendous knowledge (which we lacked) and access to press cars (which we lacked).

On this episode of Wheel Bearings, we discuss the Alfa that I borrowed, and I pick a fight about Volvo’s Sensus infotainment system. When Dan and Sam could get a word in edgewise, they discussed the cars they’ve been driving recently, as well as Sam’s experience in an automated vehicle.

Wheel Bearings is a great show you should always listen to, and I like to think this is a great introductory episode.

I’m a day late for my Thankful Thursday “thing I like” post, but yesterday was Erin’s birthday, so, I’m giving myself a bye. Keeping in the spirit of Erin, I’d like to talk about something I really love about her new car.

When we took delivery of Erin’s Volvo XC90, we were presented with this box:

I’ve never seen nor heard of keys coming in a fancy box like this, so immediately I was impressed. Everyone likes to feel special, and I felt like we were getting the white glove treatment. By comparison, though I bought my BMW used, I’d never heard of BMW keys coming in a fancy box like that.

However, the box isn’t what I want to talk about. I want to talk about that little piece of plastic that’s hiding in the right-hand side of the box. I took out the other full-size key so you could see it. The thing I like this week is the Volvo “Key Tag”.

Erin’s XC90 has a proximity key, which it refers to as a “Passive Entry” and “Passive Start” system. In BMW nomenclature, it’s a part of “Comfort Access”. Regardless of the marketing name, the… well… key here is that you don’t need to ever touch the car key to enter and start the car. For someone who keeps his keys in his pocket, this is a fantastic feature that now I’m not sure I can live without. I can only imagine how convenient this is for someone like Erin who keps her keys in her purse.

In order to open either of our cars, we simply need to grab the door handles, as long as the key is on our person. Once we get in, we can turn the car on without touching the key. When we exit, we keep the key on us, and touch a special part of the door handle to lock the car. This largely obviates the traditional remote lock/unlock features of our car keys. I almost never use my car key to lock or unlock my car remotely; I only do so by grabbing the door handle.^[1]

When it came time to claim one of Erin’s keys as my own, I immediately knew which one I wanted: the Key Tag.

Erin’s Volvo came with two traditional—and large—keys that have all the buttons you’re used to: lock, unlock, trunk release, and a panic button. But the Key Tag is the thing I like for this week.

The Key Tag also works as a proximity key, but doesn’t have any buttons on it. By not having any buttons on it, that means the Key Tag can be much much smaller than the full-size keys with remote lock/unlock. For someone who carries his keys in his pocket, that makes a world of difference. Further, the Key Tag is totally sealed, which means it’s also waterproof.

Since Erin wanted to carry a full-size key in her purse, I got my choice of either the other full-size key, or the Key Tag. Without hesitation, I chose the Key Tag. Even if this were primarily my car, I’d almost certainly^[2] still choose to carry the Key Tag over one of the traditional keys. Having that much less in my pocket is fantastic, and I wish there were an equivalent for my car.

There’s a lot to like about Erin’s car, some of which I may talk about in the future, but the seemingly simple Key Tag may be my favorite.

For the last year and a half, I’ve been working full time as a Swift developer. I love Swift, and I’ve also been really enjoying diving into Functional Reactive Programming using RxSwift. Nevertheless, I find myself longing for something that I don’t have anymore: a robust introspection API.

When I was writing C#, I could write a simple class like this:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Now let’s say I want to send or receive a Person from a RESTful API. Perhaps the transmission will be JSON, and it will look something like this:

{
    "fn": "Casey",
    "ln": "Liss"
}

If we wanted to map a C# Person from a JSON dictionary, it’s reasonably straightforward, except that there’s an important discrepancy: we need to tie fn to FirstName and ln to LastName.

There’s a ton of ways one can create a link between those different names. My favorite, in C#, was to use introspection. In C#, this is called Reflection, and that’s how I still refer to it to this day.

Reflection is neat because it allows my code to learn about itself. That means I can add some metadata to my code—I can annotate it—in order to provide some supplementary information. How does that work in practice? Let’s augment the Person class, adding and leveraging a new Attribute.

public class JsonKeyAttribute: Attribute
{
    public string Key { get; set; }

    public JsonKeyAttribute(string key)
    {
        this.Key = key;
    }
}

public class Person
{
    [JsonKey("fn")]
    public string FirstName { get; set; }

    [JsonKey("ln")]
    public string LastName { get; set; }
}

Now we are annotating our properties with new metadata: we’re storing the keys needed to translate to/from JSON right there inline. How do we leverage it? Let’s write a static factory method:

public class Person
{
    [JsonKey("fn")]
    public string FirstName { get; set; }

    [JsonKey("ln")]
    public string LastName { get; set; }

    public static Person FromJson(string jsonString)
    {
        var retVal = new Person();
        var properties = typeof(Person).GetProperties();
        foreach (var property in properties)
        {
            var attribs = property.GetCustomAttributes(typeof(JsonKeyAttribute), true);
            var attrib = attribs.FirstOrDefault() as JsonKeyAttribute;
            if (attrib != null) 
            {
                var key = attrib.Key;
                var value = // Get value from JSON object 
                            // using the key we just discovered.
                // Set the property's value
                property.SetValue(retVal, value);
            }
        }

        return retVal;
    }
}

Admittedly I’ve fluffed over the conversion from JSON string to something meaningful, as well as glossing over extracting "Casey" and "Liss" from the JSON. However, the rest of the code is the point. We can leverage Reflection to look at the Person class and see what the key is for each of its properties.

Having the ability to annotate our code with information about itself is super powerful. Using an Attribute, we were able to leave information about how to convert between different representations of the same data right in the class that needs to know about it. Some purists say that’s a poor separation of concerns; to me, that’s improving local reasoning.

Furthermore, using annotations can accomplish interesting things in arguably far cleaner ways.

As an example, if you want to specify a “pretty printer” for the purposes of debugging a Swift class, you can use CustomDebugStringConvertible. However, to do so, you must implement the protocol. For example:

struct Person {
    var firstName: String
    var lastName: String
}

extension Person: CustomDebugStringConvertible {
    var debugDescription: String {
        return "\(firstName) \(lastName)"
    }
}

The approximate equivalent in C# is arguably cleaner, because it doesn’t require implementing a new interface. Instead, you simply leverage the DebuggerDisplayAttribute:

[DebuggerDisplay("{FirstName,nq} {LastName,nq}")]
public class Person
{
    [JsonKey("fn")]
    public string FirstName { get; set; }

    [JsonKey("ln")]
    public string LastName { get; set; }
}

I can think of a ton of other places where reflection is useful as well. I’m particularly interested in how cool it could be to really open up the already crazy-powerful Swift enums by adding the ability to annotate them, or reflect over them. Oh, the crazy things I could do… 🤔

Reflection isn’t for everyone. In fact, I got the following email from an ATP listener:

If you need reflection to reason about and execute code runtime, your API is poorly designed. Can you please explain why you feel the the need for a reflection API?

That’s a pretty severe take-down.

I understand the sentiment, and this particular listener isn’t necessarily wrong. But what I love about reflection is that it opens up the possibility for a whole new way of solving problems. A way that I’ve found to be quite convenient from time to time.

In fact, all of you Objective-C developers out there may enjoy doing things like this on occasion:

id person = [[NSClassFromString("Person") alloc] init];

To me, that’s reflection.

A while back there was a big kerfuffle amongst some Objective-C developers who were, erm, objecting to the lack of dynamic features in Swift. To me, the canonical, level-headed post about this was this wonderful post by my pal Brent Simmons. It’s an extremely short but accurate summary of what all of the Objective-C folks seemed to think Swift was lacking.

To me, I can summarize his post in one word: reflection.

In the midst of the announcements over the last couple days, I didn’t get a chance to call out that I was on this week’s episode of the always-fun, always-brief Clockwise podcast.

This week, I joined Dan Moren, Mikah Sargent, and Kathy Campbell. We discussed messaging apps, LTE Apple Watches, how we get our news, and guilty [app] pleasures.

I always enjoy both recording and listening to Clockwise; you probably will too.

In so many ways, I’m still riding the wave.

After four years of trying, when we finally had Declan, it felt like a tremendous weight was off of our chest. As I said to Erin repeatedly over the first several days, we did it. We had finally come to the end of this arduous, seemingly endless road that we had been on. Of course, we didn’t have much time to look in our rearview mirror; infants wait for no one.

Over time, we settled into our new normal. In many ways it likely was—and remains—harder for Erin than it is for me. I disappear for 8-10 hours a day almost every day. Erin, however, has no Off position. I try to take Declan as much as I can on the weekends, but for her, she’s never really not Mommy.

Despite this, after a couple years, the struggle to bring Declan here fades, even if only slightly. It’s a memory how hard raising an infant is. We remember that visiting the fertility doctor is inconvenient, frustrating, and often fairly demoralizing; but it was so long ago. We fall out of the habit of living our lives around Erin’s cycle; remembering now it is often times disrupting.

It’s the same as it ever was.

Naturally, our ever-optimistic families have a different party line, mostly regarding Erin: “You never know! Maybe now that your body has done it once, it knows exactly what to do!”

😑

It was quickly apparent that we were not that lucky.

As we restart our journey, Erin and I don’t realize that it’s disrupting to more than just us now. It’s exceptionally selfish to bring a child to a fertility clinic, so that means we need to ask family or our friends to watch Declan as we go. We have to schedule appointments around not only our own schedules, but that of another person entirely: Declan.

Perhaps it’s not that much like last time after all.

What’s most striking, though, is how different our attitudes are. When we were walking this path trying to conceive Declan, every single moment was monumental. Every time seemed like our last shot, even when it really wasn’t. Every time we were worried, scared, nervous, and most of all, hopeful.

As Erin and I start following the same procedures, and have the same kind of help as we did last time, we realize how this is our new normal. Even moreso than with Declan. While it definitely sucks, going through all these motions doesn’t carry the same weight it did. Even if we can’t conceive this time, we’ve still succeeded already; we’re still parents.

We got lucky… again.

We’re so happy to share that Erin is pregnant again!

As I write this, Erin is 19 weeks along. So far, everything seems well. Erin had the pleasure of dealing with a fair bit of nausea for the first trimester, but for the last several weeks, that has subsided. To my eyes, she’s showing more—and sooner—than last time. I find that adorable; Erin is still… adjusting. 😉

Someone else, however, has been particularly interested in the goings on.

As with last time, we needed to pick a designated emoji. “Sprout”—🌱—is a high bar. After much deliberation, Erin and I landed on “Sprig”—🌿.

We don’t know 🌿’s gender yet, but there’s a sealed envelope in our house that does. This may be our last opportunity to get the surprise of the gender at the time of birth, so we’re attempting to hold out. That said, a smart gambler would bet on us caving and opening that envelope sooner rather than later.

Declan refers to Sprig as a “he”, but he talks about his “baby sister”. 🤔 As one would expect, Declan has also informed us that he, too, is growing a baby in his belly. In fact, he’s even asked for us to take a picture of his growing belly before we take weekly shots of 🌿. 😂

We’re petrified, but excited. We’re thrilled, but worried. So much of this feels so much different than last time. We’re more relaxed, and yet, in so many ways, it’s the same as it ever was.

Either way, if all goes to plan, we’ll meet you in the first week of January, Sprig. Well, unless you come early, like Declan did…

I know I speak for your momma, and your older brother, in saying:

We can’t wait to meet you.

Last Thursday, I discussed youtube-dl, a tool that allows you to easily download various kinds of media from the web. What happens once you have that media? Or what happens if you want to do something with media you already have?

ffmpeg is almost always the answer. It can take nearly any form of audio or video media and convert it to almost any other form. It can extract clips, transcode media, rotate it, crop it, downsample, upsample, etc. ffmpeg is truly omnivorous.

In fact, many media players and/or transcoders that you may know and love are actually just graphical front-ends for ffmpeg. Handbrake and Plex are two examples that spring to mind.

I’ve spoken about ffmpeg many times in the past, and I’ve often been asked to write a primer on how to use it. To cover every nook and cranny of ffmpeg would take forever, so instead I’ll just cover a handful of examples I find myself using often.

Installation

The easiest way to install ffmpeg is to use Homebrew:

brew install ffmpeg

There are some nuances to installation if you want support for certain sub-sets of functionality, but the above will at least get you started.

Basic Usage

Let’s say you downloaded a file using youtube-dl and it ended up in a format you didn’t expect:

youtube-dl "https://www.youtube.com/watch?v=s64RnXSwn-A"

The resulting file is of type .mkv; let’s say the full filename is input.mkv just to make things easier. MKV files are not a format that Apple OSes tends to like. Let’s suppose you want to convert that into something more Apple-friendly, like a .mp4. That’s simple to do:

ffmpeg -i input.mkv output.mp4

We’re using the -i parameter to specify the input file to ffmpeg, and then we’re simply specifying the output file. By virtue of the .mp4 extension, ffmpeg is smart enough to divine what to do.

Similarly, if we wanted to extract the audio from this video after we’ve already downloaded it, we could do so as such:

ffmpeg -i input.mkv output.mp3

Again, the presence of .mp3 will tell ffmpeg all it needs to know.

Trimming

If you actually watch the video, there’s an intro section and an outro section that we really don’t need. The intro ends at 46 seconds. We can instruct ffmpeg to start the output at that point:

ffmpeg -i input.mkv -ss 00:00:46 output.mp3

Here, we’re using the oddly-named -ss parameter to set the hours:minutes:seconds into the input we wish to seek before we start “recording”, so to speak.

However, we haven’t gotten rid of our outro yet, which lasts for the last six seconds of the video. We can handle that using the -to option, which sets when to stop processing the input file, in the time system of the input file. Since output.mp3 is 4:34 seconds, then we need to subtract 6 from that, to land on 00:04:28:

ffmpeg -i output.mp3 -to 00:04:28 trimmed.mp3

What if we wanted to do both at once? We can use the -to parameter to set the end point (again, in terms of the input), in addition to the -ss to set the start time. Note, though, we’re using the original file as the input again. Thus, we have to change the end point for the -to since we’re starting from the full file, not the one with the intro clipped. Finally, we land on this “compound” command:

ffmpeg -i input.mkv -ss 00:00:46 -to 00:05:13 trimed.mp3

In one shot, we’ve:

• Stripped the audio
• Transcoded the video
• Trimmed the beginning
• Trimmed the end

Pretty cool stuff, and pretty easy, once you learn to speak ffmpeg.

Cropping

What if you download a different file, but it has bars on the top/bottom or left/right?

youtube-dl "https://www.youtube.com/watch?v=tTiiDQ03eSQ"

In this case, we’d like to remove the small black bars on the left and right sides of the video. We know we need to take off about 10 pixels total; 5 on both the left and right sides. We can do so by using a video filter:

ffmpeg -i input.mp4 -vf "crop=in_w-10:in_h" cropped.mp4

The crop parameter to the -vf (video filter) parameter indicates what the resolution of the width and then height of the output video should be. We use the in_w and in_h macros to indicate the source width and height; then we subtract 10 from the width.

Codecs

Continuing with the above example, we can make this ever-so-slightly faster. We know that we want the final file to be in the same format—.mp4—as the source was. Since we’re not doing any sort of modifications to the audio, we can tell ffmpeg to copy the audio codec:

ffmpeg -i input.mp4 -vf "crop=in_w-10" -acodec copy cropped.mp4

Since the audio is far easier to process than the video, this isn’t the best example, as the time savings are marginal. However, in some cases, you may be able to get away with copying the video codec using -vcodec copy. In those cases, that is a big time savings.

It’s beyond the scope of this article, but a nice way to figure out if you can leverage -vcodec copy is to run a command with no output:

ffmpeg -i input.mp4

That will tell you what the video and audio streams are:

Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 819 kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc (default)
Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 125 kb/s (default)

In our case, we know that the video is h264, which means that we can use -vcodec copy is possible if we’re converting to .mp4.

Variable Bit Rates

Related to codecs, when left to its own devices, ffmpeg will encode mp3s at a constant 128kbps. That’s sufficient, but I prefer to use a variable bit rate. To do so, we use a less intuitive incantation:

ffmpeg -i input.mkv -codec:a libmp3lame -qscale:a 2 output.mp3

This is… completely bonkers. Ridiculous incantations like these—if not the ones that preceded it—are why ffmpeg gets a bad name. However, the sheer versatility of ffmpeg makes it an indispensible tool that I can’t imagine living without.

I’ve set up a folder in the Apple Notes app with a series of “recipes” for ffmpeg. As I find a new task I want to accomplish, I determine what the recipe is, and then write it down as a new note in that folder. You may find the same tactic is useful for you. Regardless, most of that “recipe book” has been recreated above.

I know the command line is scary, but ffmpeg is worth getting over it. Everything you do in ffmpeg is non-destructive, so the only harm in playing around is wasting time and listening to your computer’s fans scream. At first I never did anything more than transcoding using ffmpeg, but over time, I’ve gotten to be pretty confident with it.

I recently wrote about BMW’s The Hire series, starting a hopefully-weekly series about things that I like. That was… two weeks ago. Can’t win 'em all.

Nevertheless, today I’m back at it, and I have something else I like that I’d like to highlight: youtube-dl.

Have you ever wanted to download something that was available on YouTube? Perhaps you wanted to grab only the audio, but didn’t need the video? Perhaps, of a song you enjoy or of a concert you recently stumbled on. Maybe you want to grab something that isn’t on YouTube at all?

youtube-dl can do all of these things. And much, much more.

youtube-dl is a command line utility that allows you to download video (or, if you prefer, only the audio) from a staggering list of websites. I know that as soon as I say “command line”, many will go running. Seriously though, it’s really simple:

youtube-dl "https://www.youtube.com/watch?v=pngDPqubloo"

Wait a little while, and you’ll have a download sitting on your local disk.

What if you just want audio? Easy-peasy.

youtube-dl -x "https://www.youtube.com/watch?v=iCXItGrjqrw"

What if you wanted to download something that, as far as you can tell, is only available via streaming via the web? In many instances, you can use the developer tools in your browser of choice to find the m3u8 playlist that is being streamed, and feed that to youtube-dl. It will download the stream and save the result locally. This has… come in useful… from time to time.

youtube-dl is a staggeringly useful tool that I use easily every single week. If you’re one who likes to build up a large library of oft-watched videos, it’s indispensible. Or, perhaps if you are just wanting to watch a video on a long flight, you can download it onto your laptop in advance. Either way, there are other tools similar to youtube-dl, but I’ve not found one I like more.

We’ve heard some interesting things over the past few weeks:

• The next iPhone may support wireless charging
• The next version of Xcode supports wireless debugging
• The existing iPhone is water resistant, to about a meter
• The iPhone 7 dropped the headphone jack

Could the next iPhone—particularly a special edition halo like the “iPhone Pro”—have no ports at all?

Most obviously, the headphone jack is already gone. Furthermore, we’ve been programmed that Bluetooth audio is the future. If we add wireless charging, do we really need a lightning port anymore? Especially in a halo phone? We’ve made this sort of thing work with the Apple Watch already^[1].

Given that I’m sitting at the beach, I can imagine quite a few ways where one could easy market a phone that has no ports, and as such, is considerably more water resistant.

This surely isn’t an original idea, but the more I think about it, the more I think it makes sense. Especially in the context of a specialty Pro iPhone.