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:
Host example.com
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.
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!
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 employ, 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 as appropriate.
While my examples use Keynote, the technique can be applied in other presentation software using their own appropriate features.
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.
When faced with two of more alternatives that deliver roughly the same value, take the path that makes future change easier.
From Agile Is Dead (Long Live Agile) by Dave Thomas.
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.
You are building something for someone. Whether that someone are other people just like you, people mostly like you, or people completely different from you, you need to understand your user. This also means that being a better developer isn’t a once-and-done event. It’s something you have to constant work at.
So, next time you get a project, care about the user. Understand the user, and make sure the software is the best possible product you can create for that user.
We easily forget how even the simplest of things that we can do are magic to so many others. That means we can’t just make them happy. We can’t just give them what they want. We have to give them the best experience we can. Great programmers can do that. They know their audience, they know the needs of the users, and they work hard to give them the best experience.
This is true for both GUI applications and libraries and frameworks. We’ve all had the joy of working with code that that was elegant to use and well documented. A well defined interface with solid documentation is a developer caring about his user: other programmers.
So, care about your users, whether they be other programmers or people who don’t know what a browser is.
The best developers know they can’t do everything, and they also know what they don’t know. They aren’t afraid to ask for help, or to talk things over. Those great developers you know discuss and plan, and rely on a great team. If you want to become a better developer, you need to be willing to admit when you don’t know something.
This means asking questions when you are unsure. Checking your ego at the door, and being comfortable saying “I don’t know” or “I’m not sure.”
One of the hardest things for me to do is to ask for help. Which is silly, of course, because whenever I’ve asked for help, those I’ve asked have been more than willing to help. What I’m really afraid of is looking weak, like I don’t know what I’m doing, as if I don’t belong. It takes a real effort to remind myself that it’s okay to ask for help. That I don’t always have to have all the answers. That the best solutions I’ve ever come up with have been when discussing the topic with others.
This also means letting someone else take they lead when they are clearly better with a certain skill-set, and learning from that person. I don’t mean that you pass the problem off to them. What I mean is, don’t be afraid to adopt someone else’s solution. A part of you might think that it will highlight the fact that your solution wasn’t as good. What really happens is that you recognized that your solution could be better, and because you were stuck, you sought a better solution. And now you get to implement a better solution. And that better solution makes for a better experience for your end user.
And in the end, that’s what matters.
Once you know your limitations, it’s important to try and break through those limitations. The obvious solution is to learn what you don’t know, and I cover that next. However, not all things are as simple as reading a book, finding an answer on StackOverflow, or finding some article on a blog.
In many cases, it’s doing things. Later, I talk about teaching. However, if you are afraid of speaking in front of people, or you aren’t comfortable doing it, you’ll be less likely to teach people. Granted, you could go the route of doing it from the comfort of your own blog, but you’ll be living within your self-imposed limits.
This means never saying you can’t. It’s fine to say you don’t know how, or you’ve never done something. And the more you do, the harder things will get (because I assume that you’ve tackled a lot of easier things along the way). But challenges and difficulties shouldn’t stop you. You should look at every challenge and difficulty as an opportunity. Treating them as opportunities puts you in the right frame of mind. One of overcoming those challenges and limitations.
This should come as no surprise, but at the end of the day, you also need to keep learning new things. There are many professions were constantly learning is the norm, and programming is one of them. You can, of course, stagnate, and not learn new languages or tools. You can allow yourself to fall behind the curve. But sooner or later, those new tools will become the norm, and you’ll be playing catch up.
This doesn’t mean you invest equally into all new languages and tools. You have to pick and choose what you are investing your time in. There are far too many new technologies coming out these days for you keep up to date on everything. However, many of these technologies are based around well-established principals.
There are two areas I’d say people should invest time into learning. One is JavaScript, and by extension, Node.js. The other is mobile development. If you have an Android phone, learn Android development. If you have an iPhone and a Mac, learn iOS development. Learn native development for either platform.
Learning JavaScript should be a no-brainer. With the power of Node.js, and every browser worth supporting having JavaScript, it would be silly not to spend time learning JavaScript. You’ll be able to handle server side programming, as well as client-side web programming in one language.
The mobile-side should be equally obvious. These are two areas that are growing, and as we see wearable technologies come out from Google, eventually Apple, and others, we’ll see an increase in the demand for knowing how to work on these mobile platforms. iOS and Android aren’t going away anytime soon, and knowing how to write applications for them will only make you a better developer.
It’s equally important to teach others. I’ve covered this briefly in my article on the benefits of speaking, but teaching forces you to learn the topic well enough that you can teach it to others so that they can make use of it.
As a developer, you might know a lot of frameworks and how to use various languages and editors, tools and systems to make yourself more productive. But until you’ve actually taught people how to use these tools, can you really say you know them? After all, at the comfort of your desk, you have Google and StackOverflow at hand to handle any problems you might run into. You can stop to check email, go get some coffee, and otherwise ponder what to do next.
But when you are teaching, you really are on the spot. Every eye is on you, and when someone asks a question, you either know it or you don’t. There is no harm in not knowing an answer to a question. But you have to admit it, and quickly. You have to humble yourself, because to give the wrong answer is the absolutely wrong thing to do at that point.
I’m not going to pretend this covers everything you can possibly do to become a better developer. However, I do know that these are things we should always be practicing. I’m curious if you have other things developers can do to better themselves.
I’ve been thinking 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.
That network call out to Facebook has to do a lot. It has to travel a much 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 fairly 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 signup. Then you needed to send out an email. You also needed to update the mailing list database on signup. And now you need to run another set of operations for fighting spam.
The easiest solution to doing more is to not do more at the time 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.
Jason Lotito 