Deployed 25512d6 with MkDocs version: 0.15.3

index.html

@@ -117,6 +117,8 @@
             
                 <li class="third-level"><a href="#you-will-thank-you">You will thank you</a></li>
             
+                <li class="third-level"><a href="#nothing-here-is-binding">Nothing here is binding</a></li>
+            
         
             <li class="second-level"><a href="#getting-started">Getting started</a></li>
             
@@ -157,30 +159,44 @@
 <h1 id="cookiecutter-data-science">Cookiecutter Data Science</h1>
 <p><em>A logical, reasonably standardized, but flexible project structure for doing and sharing data science work.</em></p>
 <h2 id="why-use-this-project-structure">Why use this project structure?</h2>
-<p>We often think of data analysis as just the resulting report, insights, or visualizations. Even though these end products are generated by code, it's easy to focus on making the products <em>look nice</em> and ignore the <em>quality of the code that generates them</em>. While these end products are generally the main event, <strong>code quality is still important</strong>! And we're not talking about bikeshedding the aesthetics or pedantic formatting standards — it's ultimately about correctness and reproducibility.</p>
-<p>It's no secret that good analyses are often the result of very scattershot and serendipitous explorations, tentative experiments, and rapidly testing what works and what doesn't. That is all part of the process for getting to the good stuff, and there is no magic bullet to turn data exploration into a simple, linear progression. That being said, once started it is not a process that lends itself to thinking carefully about the structure of your code or project layout.</p>
-<p>We think it's a pretty big win all around to let someone else do that up-front thinking and setup for you. Here's why:</p>
+<blockquote>
+<p>We're not talking about bikeshedding the indentation aesthetics or pedantic formatting standards — ultimately, data science code quality is about correctness and reproducibility.</p>
+</blockquote>
+<p>When we think about data analysis, we often think just about the resulting reports, insights, or visualizations. While these end products are generally the main event, it's easy to focus on making the products <em>look nice</em> and ignore the <em>quality of the code that generates them</em>. Because these end products are created programmatically, <strong>code quality is still important</strong>! And we're not talking about bikeshedding the indentation aesthetics or pedantic formatting standards — ultimately, data science code quality is about correctness and reproducibility.</p>
+<p>It's no secret that good analyses are often the result of very scattershot and serendipitous explorations. Tentative experiments and rapidly testing approaches that might not work out are all part of the process for getting to the good stuff, and there is no magic bullet to turn data exploration into a simple, linear progression.</p>
+<p>That being said, once started it is not a process that lends itself to thinking carefully about the structure of your code or project layout, so it's best to start with a clean, logical structure and stick to it throughout. We think it's a pretty big win all around to use a fairly standardized setup like this one. Here's why:</p>
 <h3 id="other-people-will-thank-you">Other people will thank you</h3>
 <blockquote>
 <p>Nobody sits around before creating a new Rails project to figure out where they want to put their views; they just run <code>rails new</code> to get a standard project skeleton like everybody else.</p>
 </blockquote>
-<p>A well-defined, standard project structure means that a newcomer can begin to understand an analysis without digging in to extensive documentation. Well organized code is self-documenting and provides a lot of context for your code without much overhead. People will thank you for this because they can:</p>
+<p>A well-defined, standard project structure means that a newcomer can begin to understand an analysis without digging in to extensive documentation. It also means that they don't necessarily have to read 100% of the code before knowing where to look for very specific things.</p>
+<p>Well organized code tends to be self-documenting in that the organization itself provides context for your code without much overhead. People will thank you for this because they can:</p>
 <ul>
-<li>Collaborate easily with you on this analysis</li>
-<li>Easily learn from your analysis about the process and the domain</li>
-<li>Feel confident in the conclusions the analysis presents</li>
+<li>Collaborate more easily with you on this analysis</li>
+<li>Learn from your analysis about the process and the domain</li>
+<li>Feel confident in the conclusions at which the analysis arrives</li>
 </ul>
-<p>A consistent project structure means less random searching for what gets called where. A good example of this can be found in web development frameworks like Ruby on Rails, Django, and most others. Nobody sits around before creating a new Rails project to figure out where they want to put their views; they just run <code>rails new</code> to get a standard project skeleton like everybody else. And because the default project structure is <em>reasonably logical</em> and <em>standard across most projects</em>, it takes almost no time at all for somebody who has never seen a particular project to figure out where they would find the various moving parts.</p>
+<p>A good example of this can be found in any of the major web development frameworks like Django or Ruby on Rails. Nobody sits around before creating a new Rails project to figure out where they want to put their views; they just run <code>rails new</code> to get a standard project skeleton like everybody else. Because that default project structure is <em>logical</em> and <em>reasonably standard across most projects</em>, it is much easier for somebody who has never seen a particular project to figure out where they would find the various moving parts.</p>
+<p>Another great example is the <a href="https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard">Filesystem Hierarchy Standard</a> for Unix-like systems. The <code>/etc</code> directory has a very specific purpose, as does the <code>/tmp</code> folder, and everybody (more or less) agrees to honor that social contract. That means an Red Hat user and an Ubuntu user both know roughly where to look for certain types of files, even when using each other's system — or any other standards-compliant system for that matter!</p>
 <p>Ideally, that's how it should be when a colleague opens up your data science project.</p>
 <h3 id="you-will-thank-you">You will thank you</h3>
 <p>Ever tried to reproduce an analysis that you did a few months ago or even a few years ago? You may have written the code, but it's now impossible to decipher whether you should use <code>make_figures.py.old</code>, <code>make_figures_working.py</code> or <code>new_make_figures01.py</code> to get things done. Here are some questions we've learned to ask with a sense of existential dread:</p>
 <ul>
-<li>Are we supposed to go in and join the "region" column to the data before we get started or did that come from one of the notebooks?</li>
+<li>Are we supposed to go in and join the column X to the data before we get started or did that come from one of the notebooks?</li>
 <li>Come to think of it, which notebook do we have to run first before running the plotting code: was it "process data" or "clean data"?</li>
-<li>Where did the shapefiles get downloaded from for the geographic plots you made?</li>
+<li>Where did the shapefiles get downloaded from for the geographic plots?</li>
 <li><em>Et cetera, times infinity.</em></li>
 </ul>
 <p>These types of questions are painful and are symptoms of a disorganized project. A good project structure encourages practices that make it easier to come back to old work, for example separation of concerns, abstracting analysis as a <a href="https://en.wikipedia.org/wiki/Directed_acyclic_graph">DAG</a>, and engineering best practices like version control.</p>
+<h3 id="nothing-here-is-binding">Nothing here is binding</h3>
+<blockquote>
+<p>"A foolish consistency is the hobgoblin of little minds" — Ralph Waldo Emerson (and <a href="https://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds">PEP 8!</a>)</p>
+</blockquote>
+<p>Disagree with a couple of the default folder names? Working on a project that's a little nonstandard and doesn't exactly fit with the current structure? Prefer to use a different package than one of the (few) defaults?</p>
+<p><strong>Go for it!</strong> This is a lightweight structure, and is intended to be a good <em>starting point</em> for many projects. Or, as PEP 8 put it:</p>
+<blockquote>
+<p>Consistency within a project is more important. Consistency within one module or function is the most important. ... However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!</p>
+</blockquote>
 <h2 id="getting-started">Getting started</h2>
 <p>With this in mind, we've created a data science cookiecutter template for projects in Python. Your analysis doesn't have to be in Python, but the template does provide some Python boilerplate that you'd want to remove (in the <code>src</code> folder for example, and the Sphinx documentation skeleton in <code>docs</code>).</p>
 <h3 id="requirements">Requirements</h3>
@@ -196,7 +212,7 @@
 <script type="text/javascript" src="https://asciinema.org/a/9bgl5qh17wlop4xyxu9n9wr02.js" id="asciicast-9bgl5qh17wlop4xyxu9n9wr02" async></script>
 
 <h2 id="directory-structure">Directory structure</h2>
-<pre><code class="none">├── LICENSE
+<pre><code class="nohighlight">├── LICENSE
 ├── Makefile           &lt;- Makefile with commands like `make data` or `make train`
 ├── README.md          &lt;- The top-level README for developers using this project.
 ├── data
@@ -356,5 +372,5 @@ from preprocess.build_features import remove_invalid_data
 
 <!--
 MkDocs version : 0.15.3
-Build Date UTC : 2016-04-27 12:25:14.105435
+Build Date UTC : 2016-04-28 23:13:35.632752
 -->

sitemap.xml

@@ -4,7 +4,7 @@
     
     <url>
      <loc>None/</loc>
-     <lastmod>2016-04-27</lastmod>
+     <lastmod>2016-04-28</lastmod>
      <changefreq>daily</changefreq>
     </url>