James Davidheiser jdavidheiser

## nbconvert-crash.ipynb

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              0 stars
            
          
                jdavidheiser
                / nbconvert-crash.ipynb
            
            
              Created
              March 2, 2015 20:43
            
              
                nbconvert crash
              
          
      Sorry, something went wrong. Reload?
      Sorry, we cannot display this file.
      Sorry, this file is invalid so it cannot be displayed.
      
          Viewer requires iframe.
      
    
## .gitignore
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]

# C extensions
*.so

# Distribution / packaging
.Python
env/

## nvd3 ipython notebook demo
{
 "metadata": {
  "name": "",
  "signature": "sha256:5ad7f762e65176fc4319940032d1c0eb966cfa2b28c2b8cd558ad72236fbcdd8"
 },
 "nbformat": 3,
 "nbformat_minor": 0,
 "worksheets": [
  {
   "cells": [

## nvd3 test
{
 "metadata": {
  "name": ""
 },
 "nbformat": 3,
 "nbformat_minor": 0,
 "worksheets": [
  {
   "cells": [
    {

## Answers.txt
The following questions were posted by CodeKata 4.  Answers are provided inline.

* To what extent did the design decisions you made when writing the original programs make it easier or harder to factor out common code?

Part 1 was very direct, with things like column numbers hard coded inline.  As a first pass prototype it was fastest to do this way, rather than adding a lot of variables and creating functions.  Part 2, however, took the same basic structure of part 1 and made it more abstract, such that it was extremely easy to factor out the common ideas by the time part 3 rolled around.

* Was the way you wrote the second program influenced by writing the first?

Yes - seeing the parallels between the two problems meant it made sense to already start abstracting some things in the second program, to make the code a bit more generic and less specific.
	# Byte-compiled / optimized / DLL files
	__pycache__/
	*.py[cod]

	# C extensions
	*.so

	# Distribution / packaging
	.Python
	env/
	{
	"metadata": {
	"name": "",
	"signature": "sha256:5ad7f762e65176fc4319940032d1c0eb966cfa2b28c2b8cd558ad72236fbcdd8"
	},
	"nbformat": 3,
	"nbformat_minor": 0,
	"worksheets": [
	{
	"cells": [
	{
	"metadata": {
	"name": ""
	},
	"nbformat": 3,
	"nbformat_minor": 0,
	"worksheets": [
	{
	"cells": [
	{
	The following questions were posted by CodeKata 4. Answers are provided inline.

	* To what extent did the design decisions you made when writing the original programs make it easier or harder to factor out common code?

	Part 1 was very direct, with things like column numbers hard coded inline. As a first pass prototype it was fastest to do this way, rather than adding a lot of variables and creating functions. Part 2, however, took the same basic structure of part 1 and made it more abstract, such that it was extremely easy to factor out the common ideas by the time part 3 rolled around.

	* Was the way you wrote the second program influenced by writing the first?

	Yes - seeing the parallels between the two problems meant it made sense to already start abstracting some things in the second program, to make the code a bit more generic and less specific.