Given the level of distrust in election systems in recent years, I became curious about verifiable voting systems – systems in which you can ensure that your vote was really counted, and counted correctly. Systems in which everyone (or at least interested parties) can verify that election results precisely reflect the votes cast. The verifiable voting system I’ll describe is pretty close to “regular” voting for voters. They don’t need to care the election is e2e verified, they just need to vote like normal.

This document is adapted from an internal document I wrote for one of my clients, LogicHub. They’ve graciously allowed me to adapt it and share it as the blog post you’re reading now. As a reviewer, your primary goal is to find bugs before code is merged. Your secondary goal is to keep the code quality as high as possible, within reason and the time constraints of the moment. Depending on the situation, code reviews can also be a valuable venue for mentorship.

There’s a common misconception that neural networks’ recent success on a slew of problems is due to the increasing speed and decreasing cost of GPUs. In reality, that’s not the case. Modern processing power plays a critical role, but only when combined with a series of innovations in architecture and training. You can’t process million-image datasets like ImageNet without a GPU, but without Resnet you won’t be able to achieve good results.

Many seasoned engineers working in JVM based languages have seen errors like this: [error] (run-main-0) java.lang.OutOfMemoryError: unable to create native thread: [error] java.lang.OutOfMemoryError: unable to create native thread: [error] at java.base/java.lang.Thread.start0(Native Method) [error] at java.base/java.lang.Thread.start(Thread.java:813) ... [error] at java.base/java.lang.Thread.run(Thread.java:844) OutOfMemory…err…out of threads. On my laptop running Linux, this happens after a paltry 11500 threads. If you try the same thing in Go by starting Goroutines that sleep indefinitely, you get a very different result.

To say my first foray into Rust was a frustrating struggle would be an understatement. I picked a terrible first project that left me neck deep in Rust’s trickiest areas right off the bat. I was excited to try again. A few years ago I wrote Sumoshell, a CLI App for log analysis. I’d wanted to improve it for a while, so porting it to Rust seemed like a nice way to kill two birds with one stone.

Somehow I made it this far without actually understanding how sudo works. For years, I’ve just typed sudo, typed my password, and revelled in my new, magical, root super powers. The other day and I finally looked into it – to be honest, the mechanism is not at all what I expected. After going through the basics, we’ll walk through creating our own version of sudo. How Sudo Works sudo is just a regular old program that essentially does 3 things:

Two years ago in February 2016, frustrated and not feeling motivated by the 9 to 5, I quit my job. But, living in the Bay area is expensive, so I started freelancing. It’s been a life changing experience – I have control of my schedule, I have way less stress, and coding is fun again. It’s definitely not for everyone. If you don’t mind a little uncertainty and less choice on what you work on, the benefits far outweigh the downsides.

Before I start this post, let me preface it by saying that I’m not an experienced Rustacean by any means. The excellent foks at /r/rust gave a lot of helpful feedback and cleared up some misconceptions I had. Futher errata and corrections are appreciated. This post is aimed at helping other fledgling rust-learners avoid my mistake. First, by helping Rust learners pick good introductory projects that will fit naturally in idiomatic rust.

Someone recently lamented to me that try as they might, they can’t seem to instill a culture of non-manual testing in their team. This problem pervades startups, especially in those with a lot of newer developers. My theory: To foster a culture where software engineers are internally motivated to write good tests, make it harder to run your app locally and easier to write and run tests. To put it another way: rather than investing time in enabling people to run a standalone app on their laptops, invest time in making it easy to write tests.

If you read my recent post about Postgres you may have noted that Postgres operates primarily with fixed-size blocks of memory called “pages.” By default, Postgres pages are 8KB. This number is tuned to match operating system page sizes which are tuned to match hardware cache sizes. If you were to run Postgres on hardware with different cache sizes than Postgres was tuned for, you may be able to pick a better page size.