BjornDCode

// Source: https://twitter.com/calebporzio/status/1151876736931549185

<div class="flex">
    <aside class="h-screen sticky top-0">
        // Fixed Sidebar
    </aside>
    
    <main>
        // Content
    </main>

schrockwell

defmodule MyApp.Ecto.Atom do
  @behaviour Ecto.Type

  #
  # BEHAVIOUR
  #

  def type, do: :string

  def cast(value) when is_binary(value) or is_atom(value) do

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.