Devember 2016 – Day 4

Day four is done. Got the UI up today, though it’s very basic.  Decided that the API builder should, obviously, not worry about HTML output.  It should be focused on outputting results as if it’s an API, not acting as a template.  That being said, nothing prevents that from happening.  HTTP is, effectively, and API.  But the focus is on data in a format like JSON.

I streamed it once again so you can follow along with the thought process.

I think tomorrow I’ll continue with the UI, building out a system that allows you to compose commands together.

Keeping SSH connections alive

It’s actually fairly simple. In your SSH config file, you add this:

Host *
    ServerAliveInterval 240

The * after the host can be whatever host you want it to apply to, and *simply means to apply this to all hosts. So you could also apply it this way:

    ServerAliveInterval 240

Also, if you aren’t sure where your SSH config file is, on a UNIX based system, it’s generally in ~/.ssh/config.

Technology behind photos

So, we looked at JPEG image encoding, which is a very popular image codec. Especially since our image is going to be blurred heavily on the client, and thus band-limiting our image data, JPEG should compress this image quite efficiently for our purposes. Unfortunately, the standard JPEG header is hundreds of bytes in size. In fact, the JPEG header alone is several times bigger than our entire 200-byte budget. However, excluding the JPEG header, the encoded data payload itself was approaching our 200 bytes. We just needed to figure out what to do about that pesky header!

The technology behind preview photos

Performance – Or how I learned to evaluate better

1. Given what I know of this person’s performance, and if it were my money, I would award this person the highest possible compensation increase and bonus.
2. Given what I know of this person’s performance, I would always want him or her on my team.
3. This person is at risk for low performance.
4. This person is ready for promotion today.

From the Washington Post

Highlighting code in presentations

Before I started using this method, I always struggled with ways to highlight parts of code I wanted to talk about when giving presentations. This method, I’ve found, is at once the easiest method to use, and provides context to the viewer. They can easily follow along, and where the code is in relation to other code you are talking about is made apparent.


A picture is worth a thousand words, and this one should show clearly how to highlight lines of code on a slide. You just add two shapes, and set the opacity to such a level that code can still be viewed, but it’s dimmed out.

You can also generate nice transitions between highlights of the same code using Magic Move as your transition.


The result is a fairly simple transition as you highlight specific lines of code.


This works with code that cannot fit on your slide as well. Simple add the code to your slide, and allow it to go beyond the edge of your slide. When you want to highlight code that is partially hidden, simply move the text box up.


Other presentation software can do this using their own similar features.

10 Simple Things to Improve Your Tech Talks

  1. Practice your talk before speaking. Several times. Record yourself. Watch it. At a conference, people paid $$$ for this.
  2. Assume wifi is unavailable for your talk. Don’t depend on it to run demos.
  3. Assume you’ll get few or no questions. Given a 45 minute slot? Aim for 40 minutes.
  4. If you insist on live coding, make sure you’ve written down the code ahead of time. We don’t want to watch you debug in real time.
  5. If your talk title says it’s about X, don’t make the first quarter/half not talking about X. We probably came to listen to you talk about X, not your life story. Exceptions exist, but do so carefully.
  6. Waiting for audience participation is awkward. “Can anyone see what’s wrong?” Just move on.
  7. The best slides are ones that are useful after the talk. You can export with speaker notes! Have speaker notes!
  8. Be professional. Know how your computer works. How the presentation software works. Show up ahead of time, make sure tech is ready.
  9. Don’t save your talk for a big conference. Run through it at a user group or meetup. Adjust. Improve. Repeat.
  10. You can’t please everyone. Present for a target audience. Title and description should aim to entice that target audience.

Simple Startup Ideas

All too often on Hacker News, I come across a comment like this:

wouldn’t most of them be able to build something like this for internal use in a single day

Yes. Of course, it might only take a day to build, but it will be maintained forever. And that means dealing with potential bugs. That means testing. That means deploying. It means having a way to manage it. A way to scale it up. This means adding features as needed. And of course, still dealing with new bugs. It’s another system, another cog that you have to maintain.

So, next time you need to create a tool like this, stop and think for a moment. Is this built? Does this exist out there? If so, consider using the service. However, if what you need doesn’t exist, than maybe, just maybe, you’ve found yourself a new idea.

How to read more

Last year I read 37 books. I don’t pretend that this is a high number. I know that there are people that read far more books than that. However, I also know that 37 books is far greater than the majority of other people. Still, it’s important to note that I don’t read all these books sitting down turning pages. Rather, I read the majority of them as audio books from Audible. You might consider that cheating, but I don’t.

I listen to them in my car on my way to and from work. With an hour commute, I get a lot of listening time in. I also take the books with me to lunch. It gives me time to get out of the office and to take a breather. I get to catch up on a good story. It’s a great break in the middle of the day.

I’ll go for walks, and listen to a bit then, or when I’m washing dishes, or doing chores. When others might listen to music, I’ll put on my ear buds and listen to my book.

I don’t read all my books that way. I still love real physical books, and I also enjoy e-books on occasion as well. But if one of your resolutions this year is to read more, I highly recommend audio books.

Do Less

I’ve thought a lot about performance this past year. Both on the client side and the server-side as well. While it might not come as a surprise, the number one thing you can do to improve performance is to do less.

And this applies to most everything that you can actually do.

Code should do less. The more your code has to do, the longer it’s going to take. Obviously, not all operations in your language are equal, but beneath the covers, the computer has to do more.

But we need to do more

That network call out to Facebook has to do a lot. It has to travel a larger distance than keeping things local. It has to perform DNS lookups, or it has to wait around for the remote machine to do more stuff.

When that user signs up and you decide to send out that email? That’s doing more. Fetching something from cache that you’ve already got in memory? That’s doing more than you should.

It seems obvious, but at every step, you should seek to do less. And the problem is that while it’s obvious, it’s something we overlook. We forget that every action, every line will add to the cost of running the program. And no, I don’t mean that one line is equal to another. As I said before, it’s what’s happening beneath that really matters.

Of course, you can’t help but do more. After all, first it was just a simple sign-up. Then you needed to send out an email. You also needed to update the mailing list database on sign-up. And now you need to run another set of operations for fighting spam.

The Solution to doing more with less

The easiest solution to doing more is to not do more when you would normally do it. Push what you need to do off to a later time. Either using a messaging system like RabbitMQ or even later using crons, you can probably find something that will suit your needs. The best part is, if you architect it that way, instead of adding more code to the part where you’d normally add it, you are instead just adding code some place else, listening for that event.

This really emphasizes the Open-Closed principal in SOLID. Open for extension, closed for modification. Every time you find yourself modifying existing code to add a new action on a particular event, ask yourself if you really need to have that action take place at that exact time. Ask yourself if all the other processing should be held up waiting for that action to take place.