Yesterday, after a long day of my day job, in which I spend all of my
time either hacking in Typescript and React or doing a lot of dev-ops, I
decided that I was finally gonna sit down and write a little Rust. I
picked a project off my stack: "Rewrite the Unix
locate program in
Rust." The last time I had tried this, my brain didn't work at all.
About fifteen years ago at a startup, I built a very data-heavy single page app for biologists to manage a map/reduce version of a gene sequencing engine, and because it was data heavy, it made use of templates to render much of the HTML. If you've ever been in this situation, you reach for a library.
With HTML Templates, you might not need a library. But I suspect you're going to want one.Continue Reading
If you've worked in this business for a long time, you've definitely encountered that mid-size company where every team has their own favorite language. And while this might work for awhile, it's a long-term disaster waiting to happen within your company. Eventually, every company that grows to a certain size and survives realizes that you need to clamp down and have at most four computer languages allowed inside your build process.
Four languages is the minimum every company needs, because every company needs the following:
You need to decide up front which of these you're going to use, and stick with them. The reason is simple: if you limit the languages that are in use in your company's software projects, no project will be a mystery to anyone else. No one will have to deal with "Microservice X is failing, but only three people know how to fix it" problem. By restricting the list of languages your company uses, you guarantee portability of skills across the enterprise, and you provide a safety margin in case one of your core developers gets hit by a bus.Continue Reading
Chris Coyier has an article called The Widening Responsibility of Front-End Developers and what I find most interesting about the article is how it skates over one of the most critical issue in web development since the release of Backbone.js: the emergence of data-driven websites. In the same way that a travel magazine, a cooking magazine, and a copy of the an annual farm report are different, so there are lots of different kinds of web development: the first is light and fluffy and needs no data; the second has some important data needs, especially if you allow for things like ingredient substitution, modifying serving counts, and nutritional information; the last is incredibly data-driven, being almost nothing but tables and charts.Continue Reading
As I've been working on my own little Zettelkasten engine, I've realized that there are exactly two operations that matter more than any other. The client will handle many of the details of showing notes and note collections (called "boxes", since Zettelkasten literally means "note box"), but the server needs to do exactly two things exactly right every time:
Reading paper in computer science is itself an important skill, one you should master. I've detailed some of my problems before in my series on A Play On Regular Expressions, and now that I have a little free time on my hand I'm going to dive into some of the issues that I want to cover in the future.
My Regular Expressions series talked mostly about two different papers: Fischer, Huch and Wilke's A Play on Regular Expressions, and Matt Might's Parsing with Derivatives. One isn't about Brzozowski's derivatives at all; it's about identifying a common mathematical principle by which the boolean yes/no Finite State Automata of the classic Kleene Algebra can be tranformed into a Finite State Transducer by abstracting "up one level" what the automata does. The second describes a long-neglected algorithm for solving the Kleene Algebra that promises some interesting characteristics. My contribution was to show that these papers are compatible— that Might's combinators are actually semirings in disguise— and that Brzozowski's algorithm can be expressed in a systems language with strict memory requirements.
But that's not where the story starts. The story starts with two other papers, one of which I'll be reviewing today. The first paper is Joshua Goodman's 1999 paper, "Semiring Parsing," which I'll be addressing later.
Today's paper is
... by Scott Owens, John Reppy, and Aaron Turon.Continue Reading
Alice laughed. "There's no use trying," she said. "One can't believe impossible things."
"I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."
I know I've commented before on how, while Clean Code has its place, there are adherents who adhere to it so literally and unthinkingly that they've constrained their careers and condemned themselves to the same silos for the rest of their professional lives.Continue Reading
As I'm building out the design and model of Scarlett (which seems dangerously likely to get renamed 'Notesmachine' at the rate I'm going), I've hit one of those architectural things that annoys me. Allow me to ruminate on the problem.
As mentioned in the previous post, the traditional organization of any notes system is that of the Forest; each Box contains notes, some of which are the roots of trees, and the rest of which are nodes of the tree leading to leaves, which are notes that have no descendant notes.
On the other hand, I have interests that are orthogonal to that design. Let's take them in order:Continue Reading