Gramme is a grammar driven modal editor. Part 1 covered the motivation for Gramme. This post will dive into the model underlying how Gramme works. Following in the tradition of Vim, it uses the concept of modes to determine how to process user input. Pressing the / key in insert mode will insert a “/” character wherever the cursor is in the current buffer. In command mode, the / key signals the start of a search, allowing the user to search for any literal string in the current buffer.
Just before the beginning of my senior year as an undergrad studying math and computer science my computer broke. My university had hopped on a bandwagon of new hybrid tablet/laptop at the start of my program, requiring every student to buy these early-adopter models and designing the program around digitized hand-written content. I ended up with the Fujitsu T4220. It was heavy, awkward to use as a tablet, and most importantly expensive to purchase and repair.
A GADDAG is a highly specialized form of a trie data structure optimized for time-efficient queries appropriate for crossword-style word games, like the board game Scrabble. The data structure was first described by Steven Gordon in his 1993 paper titled A Faster Scrabble Move Generation Algorithm, which describes the tradeoffs between the GADDAG and its primary competitor, the Directed Acyclic Word Graph (DAWG). I found the paper early on in my computer science education.
I’m a programmer. Most, if not all, of my posts contain snippets of code. Most programmers prefer to read code with some form of syntax-based highlighting, myself included, making it an essential feature of any blogging platform. Until recently, I was using a client-based syntax highlighting solution, from prism.js. It worked well, was fantastically customizable, and supported a wide range of languages, but added significantly to the weight of each page.
I’m making a second attempt at getting this blog up and running. I had recurring issues with running Jekyll on windows; setting up Ruby, compiling modules from source, struggling with missing Visual C++ compilers. I needed something easier. After playing around with Harp (not quite flexible enough), Hexo (too much overhead from Node.js on windows), and a few others, I settled on Hugo.
I’m a software guy. I’ve taken the requisite college classes and understand how the programs I write eventually compile down to machine instructions and how they’re executed on the underlying hardware, but the idea of working directly with embedded systems for side projects at home has always been a little daunting. I haven’t touched C, C++, or similarly low-level languages in several years, and haven’t had much cause in my professional work to look into embedded devices, but learning to work on these types of platforms has always had a kind of mysterious allure for me.
Composition is a key aspect of successful design, both in art and engineering. Breaking creations down into smaller, reusable patterns lends familiarity to novel designs, providing both a starting point and guiding path for evolving new user experiences. The value of composition is especially apparent in software engineering, where both the costs of developing as well as maintaining and improving an application over time have a significant impact on the lifetime profitability of the product.
Sphere of Influence has been attending various career fairs at Virginia Tech for the last several years, looking for the best and brightest students to hire as interns and future full time employees. We’ve found it difficult, however, to shape an interview process appropriate for students at various stages in their education. This year we decided to do something to help fix that. Back in late July, about a month and a half before the event, I came up with the idea of trying to gather data on what technologies Virginia Tech students were being exposed to during their education, as well as their level of comfort with these technologies.
Go ahead and look at this page’s source. Go on, do it! Notice the little excerpt comments? <!-- excerpt-begin --> <!-- excerpt-end --> The original version of this article was written built with Jekyll. This method is no longer used in the blog for generating excerpts. Early on in my journey to learn [Jekyll] 2, sleep deprived but determined to figure out what all the fuss was about, I decided that I wanted a way to indicate small sections of each post to feature on the main page.
This post is written in response to a blog post about the role of documentation and types in interface definition. The only thing we can tell for sure is that the function takes two arguments. We can guess the types. Maybe the first one is a string and the second one is a configuration hash/object. But it is just a guess and we might be wrong. We have no idea what options go into the settings object (neither their names nor their types) or what this function returns.