Tag Archives: code

Scrollycoding – A New Way to Write Code Walkthroughs

The past few months Rodrigo Pombo has been working on Code Hike, a new way to write code walkthroughs for blogs or docs. Recently he shared this preview of the step scroller (“scrollycoding”) component.

Looks great!

Scrollycoding Demo →

Does code need to be perfect?

Andreas Creten, founder of Made With Love, on different needs in code quality depending on what type of product (POC, MVP, …) you are making.

Until your MVP really gets traction you can run on shitty code or even do things manually to prove you have a product/market fit. Only once you nail it and the customers start flowing in, you should start caring about code, but up until then, you’re almost writing one-off code too.

I especially like this part too:

Every week I talk with people with great ideas, but a tiny budget to execute them. When they ask me what it would cost to build their idea, I answer between 10k and a couple of billion, basically bouncing the question back and asking what they want to spend on it.

To me this quote relates to this chart on value over time:

done-is-better-than-perfect

One can spend a truckload of cash on a certain idea or feature, but let’s face it: the actual value is added in the first few iterations. There’s this point in time where it longer pays off to extensively put work into something. The end result might not be as polished, but it gets things done.

Does code need to be perfect? →

Spectacle CodeSlide: Present code with style

spectacle-code-slide

Present code with style using spectacle.

Awesome way to present code, and putting the focus of the reader where it needs to be. It also lets you jump to specific lines even if they’ve already been displayed before (because code tends to jump).

import React from 'react';
import { Spectacle, Deck } from 'spectacle';
import CodeSlide from 'spectacle-code-slide';
import shiaLabeoufMagicGif from "./shiaLabeoufMagic.gif"
import preloader from "spectacle/lib/utils/preloader";

preloader({
  shiaLabeoufMagicGif
});

export default class Presentation extends React.Component {
  render() {
    return (
      <Spectacle theme={theme}>
        <Deck transition={[]} transitionDuration={0} progress="bar">
          // ...
          <CodeSlide
            transition={[]}
            lang="js"
            code={require("raw!../assets/code.example")}
            ranges={[
              { loc: [0, 270], title: "Walking through some code" },
              { loc: [0, 1], title: "The Beginning" },
              { loc: [1, 2] },
              { loc: [1, 2], note: "Heres a note!" },
              { loc: [2, 3] },
              { loc: [4, 7], image: shiaLabeoufMagicGif },
              { loc: [8, 10] },
              // ...
            ]}/>
          // ...
        </Deck>
      </Spectacle>
    );
  }
}

Spectacle CodeSlide (GitHub) →
Spectacle CodeSlide Demo →

In the past – when I was still working in education – I worked with snippets that fade in when advancing, or code that is executed inline. Spectacle CodeSlide would’ve been a great addition to these two techniques, and could’ve formed a replacement for the laser pointer.

Easily create new CLI aliases with `new-alias`

I love stuff like this:

1-uE8FMv0eWNQChRKyBrWR8Q

It’s a handy little alias to create aliases for commands you just ran … an “alias-generating alias”; my inner geek rejoices 🙂

Here’s the code (add it to your .bash_profile):

new-alias() {
  local last_command=$(echo `history |tail -n2 |head -n1` | sed 's/[0-9]* //')
  echo alias $1="'""$last_command""'" >> ~/.bash_profile
  . ~/.bash_profile
}

Usage: new-alias name-for-the-alias

An alias for new aliases →

Write NASA worthy code

A verifiable set of well-chosen coding rules could make critical software components more thoroughly analyzable, for properties that go beyond compliance with the set of rules itself. To be effective, though, the set of rules has to be small, and must be clear enough that it can easily be understood and remembered. The rules will have to be specific enough that they can be checked mechanically.

  1. Restrict all code to very simple control flow constructs – do not use goto statements, setjmp or longjmp constructs, and direct or indirect recursion.
  2. All loops must have a fixed upper-bound. It must be trivially possible for a checking tool to prove statically that a preset upper-bound on the number of iterations of a loop cannot be exceeded. If the loop-bound cannot be proven statically, the rule
    is considered violated.
  3. Do not use dynamic memory allocation after initialization.
  4. No function should be longer than what can be printed on a single sheet of paper in a standard reference format with one line per statement and one line per declaration.
  5. The assertion density of the code should average to a minimum of two assertions per function.
  6. Data objects must be declared at the smallest possible level of scope.
  7. The return value of non-void functions must be checked by each calling function, and the validity of parameters must be checked inside each function.
  8. The use of the preprocessor must be limited to the inclusion of header files and simple macro definitions. Token pasting, variable argument lists (ellipses), and recursive macro calls are not allowed.
  9. The use of pointers should be restricted. Specifically, no more than one level of dereferencing is allowed. Pointer dereference operations may not be hidden in macro definitions or inside typedef declarations. Function pointers are not permitted.
  10. All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings.

Some rules might seem absurd at first (No dynamic memory allocation, really?), yet think of these in the context of a lunar lander which you can’t hotpatch on the spot. The full PDF comes with the reasoning behind these rules.

The Power of Ten – Rules for Developing Safety Critical Code →

(via)