Scripting LaTeX: Create A Base Conversion Worksheet

Corey Pennycuff's picture
Sample worksheet thumbnail
Sample base conversion worksheet
created in LaTeX.

LaTeX is amazing. And frustrating. And powerful. And frustrating.

This coming Fall semester, I will be teaching an introductory programming class for engineering students. To help them understand bits, bytes, integers, etc., is to have them practice base conversions between decimal, binary, and hexadecimal. I wanted to set this up in LaTeX, but the idea of typesetting all of those tables instantly gave me a headache. LaTeX should be able to help with the monotony, but convincing it of that will be an uphill climb.


I want a single command that I can call, giving it two numbers (in decimal): (1.) the number on which to be shown in decimal, binary, and hexadecimal, and (2.) which of the 3 to not hide. The output should be a table in which every cell is a digit from the number of that base. The cells for binary and hexadecimal should line up so as to reinforce the relationship between them. The decimal cell, however, will not be split up, since it does not line up nicely with either binary or hexadecimal. Here is an example of what I want:

From Javascript Callbacks to Promises to Generators and Coroutines

Corey Pennycuff's picture

JavaScript has always been a powerful language, but it is not always pretty to look at. ES6 has also greatly improved the syntax of the language, and although it's not perfect, it's not that bad, either. Some of JavaScript's limitations are also its strengths, which is what we will see when we examine the JavaScript coroutine pattern.

Javascript is single-threaded. It is also event-driven, so that many of its functions use a callback pattern. Unfortunately, the callback pattern is ugly and cumbersome in code. Promises improved the callback pattern slightly, but it is still not as clean as it could be. The generator pattern is the latest incarnation of data-flow syntax. To get an intuitive feel for the differences between the different approaches, look at the following code examples:

The callback method:

fs.readFile('filename.txt', 'utf8', function(err, data) {
  if (err) {
    // Something failed.
  else {
    // Do something with 'data'.


Promisify A Callback Function Without 3rd Party Libraries

Corey Pennycuff's picture

I was recently working on some code in which I wanted to use Promises, but all that I had was callback-centric code. In the past, I have imported libraries such as bluebird for this particular problem, but now that seems like a bit of overkill to get just one function. I'm already using ES6, so I don't need a polyfill in order to use Promises; all that I want is a simple promisify() function. Importing an entire library for one function is, IMO, wasteful. Besides, it's more fun to write (and therefore understand at a deeper level) your own implementation, so that's what I did.

If you don't care about why this code works, then you can see it in its completed form below. If you are actually curious as to how I came up with it, then read on and I will explain it to you. The finished code is as follows:

 * Convert a callback-based function into a promise.
function promisify(fn) {
  return function() {
    let args = Array.from(arguments);
    return new Promise((resolve, reject) => fn(...args, (error, content) => error ? reject(error) : resolve(content)));


It's 2016, And You're STILL Doing Forms Wrong (And So Is Your Framework)! [Part 3]

Corey Pennycuff's picture

Defiant: A Proposal For Tool Unification.

Defiant is a Node.js module that I am writing to answer the problems that I will address in this post. First of all I must address the question: "Why the name 'Defiant'?" In order to do so, I must first make sure that you understand the mindset of current development (mainly addressed at the Node.js ecosystem, although it is not limited to such).

The Motivation For Tool Development

We should probably begin with the Unix tool philosophy. For the uninitiated, the philosophy states that programs should be small, accomplish a single task, and have a well-defined input/output mechanism. As many command-line warriors will tell you, knowing how the individual tools work saves them time and allows quick, powerful, bug-free productivity without having to reinvent the wheel for every task. It is one of the philosophies that has propelled Linux to be the powerhouse of development that it is today.

It's 2016, And You're STILL Doing Forms Wrong (And So Is Your Framework)! [Part 2]

Corey Pennycuff's picture

Forms—A better way

The better form processing that I propose is inspired by Drupal, but furthers the idea to improve on it. In order to properly understand the approach, though, you should understand how Cryptographic Signing (specifically, Authenticated Encryption) and the Galois Counter Mode (GCM) operate.

A quick overview of the GCM cipher goes like this: Given a secret key, a plaintext, and an initialization vector (IV), a GCM cipher should return a ciphertext and an authentication code. The ciphertext, IV, and authentication code is then given to the user. When the user returns, the GCM decrypt function takes in the secret key, the ciphertext, the IV, and the authentication code, and returns the plaintext. This may sound a bit complicated, so let me break it down a bit more.

The secret key is something that is stored serverside, and is preferably unique to each user. The IV is a short string that is unique to that encryption. The uniqueness is a requirement to a counter-type of encryption like GCM. In short, the IV must be different every time that the encryption is called, otherwise the ciphertext is vulnerable. Lastly, the authentication code is a string which validates that the contents of the encrypted text has not been tampered with. It does not matter if the end user is given the encrypted text, IV, and authentication code, because if the user changes any part of any one of these, then they will not validate when combined with the secret key.


Subscribe to CS Crunch RSS