I was at a local hackathon last week. In the opening ceremony, previously winning ideas were presented in order to give us, the hackers, a general direction to work in. The next day the judges, who had only just arrived for our presentations, voted for the EXACT SAME idea that we had all been shown from that winning list. The hackers clapped and congratulated the team as any good sport does. In fact no one even mentioned the elephant in the room; the team had stolen a winning idea and re-implemented it as their own. The ironic part is that…

Electroencephalogram. Also known as EEG — a device to measure electrical impulses in the brain. I’ll be bringing this wonderful contraption to the Ark Lab. What you see in the picture is the OpenBCI EEG, encompassing an open source arduino-based chip that runs on open source firmware and interfaces through open source applications. Open source is great because it means you get hack at every layer of the stack.

In some sense, OpenBCI is revolutionizing the EEG market right now. Up until recently, brain measuring devices were only found in research and medical labs. Some headsets have come out, like…

These are a few principles I’ve learned through many long, overextended projects. With many failures have come a few successes, and those successes have helped me to identify just what went wrong the other times. Learning to follow these closely has been like learning to bring a notebook to class; pivotal in introducing some order into an otherwise chaotic process.

1. Keep a daily log to track changes and why they’re necessary

I’ll forget why I did something sometimes just 10 minutes after doing it. I don’t remember most decisions the day after. Even big design decisions where I changed the…

Recursion makes quick

Reasoning, but be careful

Dragon eats its tail

struct Cons<T> {
    car: T,
    cdr: Option<Box<Cons<T>>>,
}impl<T> Cons<T> {
    fn append(mut self, v: T) -> Self {
        match self.cdr {
            Some(l) => l.append(v),
            None => {
                self.cdr = Some(Box::new(Cons{car: v, cdr: None}));
                self
            },
        }
    }
}fn main() {
    let mut l = Cons { car: 0, cdr: None };
    l = l.append(1);
}

Okay the title makes it sound like you’ll be writing game servers in 5 minutes. And you could skip straight to the source code if that is all you want. However, the objective of this article is to provide insight into the design decisions in the code, and possibly to help you conceptualize how a game server works in the general case. The article should also be useful if you are just learning the Rust programming language or its asynchronous libraries. In 150 lines it is not going to be a great game. In fact it can hardly be called…

When I began using futures in Rust I faced strange issues regarding mutability of state. For instance, the stream type is a future that never resolves, but when using it I still needed results from the closures inside. Closures are a very common and powerful design pattern, but unless you can describe your entire application as a functional chain of monadic futures (in which case why are you even using Rust?..) it is likely you have needed to modify some state variable inside a closure and still have access to it in an outer scope. …

Why isn’t C4Coin using Ethereum?

C4Coin does run on the EVM, but it doesn’t use a PoW consensus like Ethereum. Instead it uses a custom proof-of-burn consensus that does not incentivize wasting energy on an increasing hashrate ceiling.

That sounds like proof-of-stake, which Ethereum should be moving to in the future anyways. In a few years all mining will be “virtual”.

That’s a good point, but C4Coin’s two-token PoB consensus and governance objectives extend well beyond saving energy. Let’s examine the core concepts of the network.

Just for a minute let’s first imagine that the C4Coin network did run on…

Bitcoin and Ethereum contain transactions that get by with no gas fees. In fact, they’re part of the system.

When first learning that some consensus and governance could be done on-chain, my initial question was why? It doesn’t make much sense considering that nodes would be forced to pay a gas fee just to propose a block. Furthermore, what utility is there for storing data on the blockchain anyway? We typically think of the consensus operations as the “backend” operations. Where state information is embedded directly into the consensus engine. The philosophy for moving the data on-chain is similar in…