Category: Code

Posted On

After a bunch of messing around with it over my vacation, I pushed the button to mark a 1.0 release of a very, very simple NodeCG bundle you can use for event streaming as a confidence screen generator.

A short demonstration of backlogathon-confidence-screen in action.

You can find the source and installation instructions here.

During my vacation from work over the holiday season, I thought it would be nice to finally sit down with some JavaScript and figure out a few things. My hobby target for this learning has been NodeCG, which is an open source platform used to generate graphics for livestream broadcasts.

It’s very modular, so it’s possible to produce a bundle that does something specific and attempts to do so very well, and then other broadcasters can pull that bundle into their setups and use it as they wish.

It makes use of a JavaScript library called textfit, which calculates a div size (in this case, a 1920×1080 display area), and then resizes the entered text to fit that area without overflow and with avoiding word wrapping when possible. It’s a neat library, and I’m happy to have found it.

For those not in the know, a “confidence screen” is a display that is usually placed within view of on-air talent, to send them information helpful to their broadcast roles. In the case of FGC events, we generally use it to send commentators information on who is playing the current game, as well as who is next up and when ad breaks and other broadcast beats are scheduled to occur, so they can lead into them smoothly.

For those of you who know what this is, I hope you find this useful. If you aren’t aware of what NodeCG is, I hope you take a look at it and consider using it down the road in your broadcast toolchains.

This is the first in what I’m hoping will be a handful NodeCG bundles I would love to help craft that can bring high-quality production concepts to more small-audience streamers. I also plan on expanding on this bundle in the future with a more holistic and information-dense approach to confidence screen displays. (More on that later.)

Posted On

Howdy! I just finished giving this presentation at WordCamp US 2016 about code review: about why and how you should do code review on your projects.

The Presentation

Here’s a SlideShare embed of the presentation deck:

And you can download the source Keynote presentation file here.

References

I referenced a bunch of things in my talk and mentioned that you could find those sources in this post, so here’s the list in the order you’ll run across it in the presentation:

Have any questions?

If you have any questions, comments, corrections, or whatever, please contact me. I’ll be happy to hear from you.

Posted On

Howdy! I just finished giving this presentation at WordCamp St. Louis 2016 about code review: about why and how you should do code review on your projects.

The Presentation

Here’s a SlideShare embed of the presentation deck:

And you can download the source Keynote presentation file here.

References

I referenced a bunch of things in my talk and mentioned that you could find those sources in this post, so here’s the list in the order you’ll run across it in the presentation:

Have any questions?

If you have any questions, comments, corrections, or whatever, please contact me. I’ll be happy to hear from you.

Posted On

I hadn’t heard of the ScreenOS backdoor vulnerabilites, which are CVE-2015-7755 and CVE-2015-7756, until last night when I ran into some tweets about Matthew Green’s exposition on what they are and why they are so crazy:

To sum up, some hacker or group of hackers noticed an existing backdoor in the Juniper software, which may have been intentional or unintentional — you be the judge! They then piggybacked on top of it to build a backdoor of their own, something they were able to do because all of the hard work had already been done for them. The end result was a period in which someone — maybe a foreign government — was able to decrypt Juniper traffic in the U.S. and around the world.

And all because Juniper had already paved the road.

Some of his tweets on the situation explain it in even better terms IMO:

And—back to the article—on why this is important to talk about:

For the past several months I’ve been running around with various groups of technologists, doing everything I can to convince important people that the sky is falling. Or rather, that the sky will fall if they act on some of the very bad, terrible ideas that are currently bouncing around Washington — namely, that our encryption systems should come equipped with “backdoors” intended to allow law enforcement and national security agencies to access our communications.

One of the most serious concerns we raise during these meetings is the possibility that encryption backdoors could be subverted. Specifically, that a backdoor intended for law enforcement could somehow become a backdoor for people who we don’t trust to read our messages. Normally when we talk about this, we’re concerned about failures in storage of things like escrow keys. What this Juniper vulnerability illustrates is that the danger is much broader and more serious than that.

At this point, there’s no two bones about it. We need to be using encryption everywhere. And the encryption we use needs to be open source.

Posted On

At WordPress.com VIP, we are currently hard at work designing new platform services for our clients we think will help us take their sites to the next level of WordPress awesome. And today, my colleagues open sourced two of the tools we are using internally.

(Both of them are use on this very site, actually—because my blog has been running on our new platform as a test for some time now.)

The first is VIP Jetpack, which is a series of forced module activations and testing preparation we use with the Jetpack plugin suite for VIP Go. (Yes, this site and other sites on VIP Go always use Jetpack. No, it’s not a performance hog.)

The second is VIP Support, which we use to access client administration pages when troubleshooting a site. This ensures that we don’t always have admin access to client sites, but that we can assist when something goes wrong.

This project is so exciting for me, because we have a dedication to developing as much as we can in the open, a test-driven development process, and a peer review-heavy culture. I’m not actually generating any of the code you see in these repos, but that doesn’t mean I’m not proud of what we are accomplishing and how we are doing it.

By the way, the source used to power this site on that same platform is available here; I’m working on things in the open as well even though I don’t have much time to work on them. :)

Posted On

With the recent implosion of the unofficial GitHub mirror of the WordPress plugins directory, one of the plugins I install on pretty much every site I use—Civil Footnotes—ended up without a GitHub-hosted version.

I’m starting to use Git submodules to manage plugin installations and updates, so to make this easier on myself I forked the plugin to a GitHub repo earlier today.

I can’t promise I have the technical skill to update the plugin or approve any pull requests for it, but you’re welcome to it if you would like.

Posted On

I have a handful of half-baked code ideas sitting around; often I have more ideas than I have time and/or skills to implement.

What’s different about today is that I’m finding that when I get one of these ideas, the first thing I’m doing is setting up a GitHub repo for what I want to do. (Consequently, I have two completely empty GitHub repos to my name, and one that’s a fork I haven’t worked on yet.)

The interesting thing about this is that it doesn’t ever cross my mind that I shouldn’t be sharing the code I end up making. There’s no benefit I can find to hiding what I’m doing or not learning publicly. It’s possible that someone could come across my projects and tell me that I’m doing things super-wrong, but even if that happens, at least I’ll know that I’m doing something in a less than optimal way.

And I don’t think that is going to happen, anyway. Being open is the only way to be, because no matter what I think I’m going to do, I’m pretty sure there is someone else somewhere who has wanted to do the same thing, or might be interested in the ideas I’ve had.

And when that happens, there’s a chance, no matter how small, that someone will come along and contribute to the projects. When that happens, it provides me with a chance to learn from someone who probably knows more and better than I do.