'Ley Missailidis polymetis

#Ratatouille

##Back story. I was watching the film and decided to attempt to play around as attempt to cook something fun for me and my friend that has seen the film.

##Shopping List - Gets complicated because I change it based on season

A few (4)Red or Orange Bell peppers or any other sweet pepper but avoid the colour green. (it looks unpleasant)
Garlic - Just get a whole bulb
Some form of eggplant -- Japanese Eggplant makes ones life easier.

Keybase proof

I hereby claim:

I am polymetis on github.
I am polymetis (https://keybase.io/polymetis) on keybase.
I have a public key ASD0Qbo3YuW-EftORHbsI7S_i4Ehzv7B1_TjZTPaRV6mmAo

To claim this, I am signing this object:

plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this shit out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience t

plan for code that is easy to delete/replace rather than code that is easy to extend or reuse. As needs change, you're more likely to change the assumptions about what the system should do than in how many ways it should do it. If the code needs extending, it's then easy to replace it with a bit that's easy to extend
planning for code that is easy to throw away is the best way I've found to properly bake in abstraction and isolation. The question is always "if I take this shit out or change its implementation entirely, do I need to replace anything else?". If the answer is "yes", then you may be leaking into other components. Fix it. turns out when you have that, it's also suddenly easier to reuse code.
write a prototype of whatever significant task you have to do, and consider it a draft. Use it to figure out requirements or to make your first mistakes in. Throw it away. Try again. As I gain more experience I find my prototypes smaller and individually more solid, but anything where I lack experience t

	#!/usr/bin/perl

	# Emacs starter for Emacs mac port

	# Thanks to Aquamacs Project and David Reitter

	my $args = "";
	my $tmpfiles = "";

	for my $f (@ARGV) {

	defmodule Episode do
	defstruct id: nil, name: nil, video: nil, markdown: nil, post: nil

	def list do
	[
	%Episode{id: "001", post: "271", name: "Introduction and Installing Elixir", video: "1366", markdown: "1382" },
	%Episode{id: "002", post: "275", name: "Basic Elixir", video: "1367", markdown: "1357" },
	%Episode{id: "003", post: "280", name: "Pattern Matching", video: "14879", markdown: "1413" },
	%Episode{id: "004", post: "284", name: "Functions", video: "5086", markdown: "1559" },
	%Episode{id: "005", post: "298", name: "Mix and Modules", video: "5087", markdown: "1654" },