This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

updated to be more attractive

  • Loading branch information...
V David Zvenyach
V David Zvenyach committed Sep 27, 2015
1 parent c1d531a commit c1773f4f733de663b2da8f4fec9ffbc8a1038830
View
@@ -0,0 +1,65 @@
<!-- Basic Page Needs
================================================== -->
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<!-- Mobile Specific Metas
================================================== -->
<meta name="HandheldFriendly" content="True">
<meta name="MobileOptimized" content="320">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<!-- Title and meta description
================================================== -->
{% if page.title %}
<title>{{ site.name }} | {{ page.title }}</title>
<meta property="og:title" content="{{ site.name | xml_escape }} | {{ page.title | xml_escape }}" />
{% else %}
<title>{{ site.name }} | {{ site.title }}</title>
<meta property="og:title" content="{{ site.name | xml_escape }} | {{ site.title | xml_escape }}" />
{% endif %}
{% if page.description %}
<meta name="description" content="{{ page.description | xml_escape }}">
<meta property="og:description" content="{{ page.description | xml_escape }}" />
{% else %}
<meta name="description" content="{{ site.description | xml_escape }}">
<meta property="og:description" content="{{ site.description | xml_escape }}" />
{% endif %}
<link rel="canonical" href="{{ site.url }}{{ page.url }}" />
<!--[if lt IE 9]>
<script src="{{ site.baseurl }}/assets/js/vendor/html5shiv.js"></script>
<script src="{{ site.baseurl }}/assets/js/vendor/respond.js"></script>
<script src="{{ site.baseurl }}/assets/js/vendor/selectivizr-min.js"></script>
<![endif]-->
<!-- Favicons
================================================== -->
<!-- 128x128 -->
<link rel="shortcut icon" type="image/ico" href="{{ site.baseurl }}/assets/img/favicons/favicon.ico" />
<link rel="icon" type="image/png" href="{{ site.baseurl }}/assets/img/favicons/favicon.png" />
<!-- 192x192, as recommended for Android
http://updates.html5rocks.com/2014/11/Support-for-theme-color-in-Chrome-39-for-Android
-->
<link rel="icon" type="image/png" sizes="192x192" href="{{ site.baseurl }}/assets/img/favicons/favicon-192.png" />
<!-- 57x57 (precomposed) for iPhone 3GS, pre-2011 iPod Touch and older Android devices -->
<link rel="apple-touch-icon-precomposed" href="{{ site.baseurl }}/assets/img/favicons/favicon-57.png">
<!-- 72x72 (precomposed) for 1st generation iPad, iPad 2 and iPad mini -->
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="{{ site.baseurl }}/assets/img/favicons/favicon-72.png">
<!-- 114x114 (precomposed) for iPhone 4, 4S, 5 and post-2011 iPod Touch -->
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="{{ site.baseurl }}/assets/img/favicons/favicon-114.png">
<!-- 144x144 (precomposed) for iPad 3rd and 4th generation -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="{{ site.baseurl }}/assets/img/favicons/favicon-144.png">
<!-- CSS
================================================== -->
<link rel="stylesheet" href="{{ "/assets/css/google-fonts.css" | prepend: site.baseurl }}">
<link rel="stylesheet" href="{{ "/assets/css/homepage.css" | prepend: site.baseurl }}">
<!-- Scripts
================================================== -->
<script src="{{ site.baseurl }}/assets/js/vendor/jquery-1.11.3.min.js"></script>
View
@@ -0,0 +1,16 @@
<!DOCTYPE html>
<html lang="en">
<head>
{% include head-home.html %}
</head>
<body>
<div id="main" class="main-content" role="main">
{{ content }}
</div>
</body>
</html>
@@ -1,14 +1,14 @@
title: "Automated Testing"
description: |
"The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.
The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.
Acceptance test are a type of automated test that encapsulate a feature from the end-user's point of view. For example, a web application will have automated acceptance tests for user login. Acceptance tests are executed in a real browser that is coded to execute user input. On the other end of the scale are unit tests which test detailed input, output and side-effects for smallest, most isolated modules of code. In between these extremes are functional or integration tests which test the interactions between more than one unit of code. Naming of test types is inconsistent across the industry, and sometimes you will hear 'acceptance' and 'integration' tests used interchangeably.
Writing focused tests, that include detailed descriptions, provides the best possible form of documentation for communication between developers. Acceptance tests can be described in a English-like language called [Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin). Implementation for Gherkin is available in most modern programming languages. As a tool, Gherkin, extends the documentation role of automated tests, making them accessible to product managers and other stakeholders.
Running tests locally is a great tool for engineers, but the entire project benefits when tests are run after each commit to the master repository. Continuous integration servers provide this kind of project level safety net.
Almost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code."
Almost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code.
ingredients:
- Testable code
- A testing framework for your language
@@ -6,15 +6,15 @@ permalink: /recipes/automated-testing/
>
"The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.
The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.
Acceptance test are a type of automated test that encapsulate a feature from the end-user's point of view. For example, a web application will have automated acceptance tests for user login. Acceptance tests are executed in a real browser that is coded to execute user input. On the other end of the scale are unit tests which test detailed input, output and side-effects for smallest, most isolated modules of code. In between these extremes are functional or integration tests which test the interactions between more than one unit of code. Naming of test types is inconsistent across the industry, and sometimes you will hear 'acceptance' and 'integration' tests used interchangeably.
Writing focused tests, that include detailed descriptions, provides the best possible form of documentation for communication between developers. Acceptance tests can be described in a English-like language called [Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin). Implementation for Gherkin is available in most modern programming languages. As a tool, Gherkin, extends the documentation role of automated tests, making them accessible to product managers and other stakeholders.
Running tests locally is a great tool for engineers, but the entire project benefits when tests are run after each commit to the master repository. Continuous integration servers provide this kind of project level safety net.
Almost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code."
Almost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code.
## Ingredients
View
@@ -0,0 +1,208 @@
---
---
// Imports -------------- //
@import 'all';
// Variables ------------ //
$text-width: 660px;
$section-padding: 7.2rem;
// Styles --------------- //
p {
font-family: $font-sans;
font-size: 1.7rem;
}
.usa-intro {
max-width: $text-width;
}
.usa-section-examples {
@include media($medium-screen) {
.usa-width-five-sixths {
@include shift(1);
}
}
}
.usa-section {
padding: {
bottom: $section-padding;
top: $section-padding;
}
}
.usa-button-block {
@include media($medium-screen) {
width: auto;
}
display: inline-block;
vertical-align: top;
width: 100%;
}
.usa-banner {
@include media ($medium-screen) {
background-image: url("../img/home/homepage_illustrations_flag_cropped_2x.png");
background-position: right bottom;
background-repeat: no-repeat;
background-size: 582px auto;
}
background-color: $color-primary-darkest;
background-image: none;
color: $color-white;
padding: {
bottom: 3.7rem;
top: 2rem;
}
.usa-font-lead {
color: $color-white;
margin-bottom: 1rem;
}
h1 {
@include media($medium-screen) {
font-size: 5.6rem;
padding-top: 4.5rem;
}
color: $color-white;
padding-top: 1.5rem;
}
.usa-text-small {
text-align: center;
}
.usa-button-outline-inverse {
margin-right: 0;
}
}
.usa-banner-link-top {
color: $color-white;
float: right;
font-weight: $font-bold;
&:visited {
color: $color-white;
}
}
.usa-banner-content {
max-width: 48rem;
}
.usa-section-alt {
background-color: $color-gray-lightest;
}
.usa-section-dark {
background-color: $color-gray-dark;
color: $color-white;
h2,
h3,
.usa-font-lead {
color: $color-white;
}
.usa-width-one-half-top {
@include media($medium-screen) {
margin-bottom: 7rem;
}
}
}
.usa-img-secondary {
text-align: center;
img {
width: 260px;
}
}
.usa-circle-block img {
width: 124px;
}
@include media($medium-screen) {
.usa-img-circle {
float: left;
margin-right: 3rem;
}
.usa-graphic-list-heading {
clear: none;
margin-top: 0;
}
.usa-graphic-list-text {
overflow: hidden;
}
}
.usa-circle-block {
text-align: center;
}
h1, h2, h3, h4, h5, h6 {
color: $color-primary-darker;
font-family: $font-serif;
}
h1, h2 {
margin-top: 0;
}
.usa-font-lead {
color: $color-gray-dark;
font-weight: 300;
margin-bottom: 5rem;
}
.intro-text {
font-family: $font-serif;
line-height: $lead-line-height;
margin-bottom: 4rem;
}
a,
a:hover {
border-bottom: 0;
}
a {
> h3,
&:visited {
color: $color-primary;
}
}
.usa-standlast {
p {
font-size: $h3-font-size;
}
}
.usa-example-heading {
font-weight: $font-normal;
margin: {
bottom: 1.6rem;
top: 0;
}
}
.usa-section-examples {
.usa-cta {
margin-bottom: 1.6rem;
}
.usa-img-example {
margin-bottom: 5rem;
}
}
View
@@ -45,7 +45,7 @@
},
{
"title": "Automated Testing",
"description": "\"The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.\n\nAcceptance test are a type of automated test that encapsulate a feature from the end-user's point of view. For example, a web application will have automated acceptance tests for user login. Acceptance tests are executed in a real browser that is coded to execute user input. On the other end of the scale are unit tests which test detailed input, output and side-effects for smallest, most isolated modules of code. In between these extremes are functional or integration tests which test the interactions between more than one unit of code. Naming of test types is inconsistent across the industry, and sometimes you will hear 'acceptance' and 'integration' tests used interchangeably.\n\nWriting focused tests, that include detailed descriptions, provides the best possible form of documentation for communication between developers. Acceptance tests can be described in a English-like language called [Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin). Implementation for Gherkin is available in most modern programming languages. As a tool, Gherkin, extends the documentation role of automated tests, making them accessible to product managers and other stakeholders.\n\nRunning tests locally is a great tool for engineers, but the entire project benefits when tests are run after each commit to the master repository. Continuous integration servers provide this kind of project level safety net.\n\nAlmost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code.\"\n",
"description": "The [US Digital Services playbook](https://playbook.cio.gov) recommends having automated tests for your code base. While manual testing of code can be a good process, automated tests ensure greater code stability.\n\nAcceptance test are a type of automated test that encapsulate a feature from the end-user's point of view. For example, a web application will have automated acceptance tests for user login. Acceptance tests are executed in a real browser that is coded to execute user input. On the other end of the scale are unit tests which test detailed input, output and side-effects for smallest, most isolated modules of code. In between these extremes are functional or integration tests which test the interactions between more than one unit of code. Naming of test types is inconsistent across the industry, and sometimes you will hear 'acceptance' and 'integration' tests used interchangeably.\n\nWriting focused tests, that include detailed descriptions, provides the best possible form of documentation for communication between developers. Acceptance tests can be described in a English-like language called [Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin). Implementation for Gherkin is available in most modern programming languages. As a tool, Gherkin, extends the documentation role of automated tests, making them accessible to product managers and other stakeholders.\n\nRunning tests locally is a great tool for engineers, but the entire project benefits when tests are run after each commit to the master repository. Continuous integration servers provide this kind of project level safety net.\n\nAlmost every programming language has freely available, open-source testing frameworks. In addition, there are code coverage tools that calculate how well the tests cover the code.\n",
"ingredients": [
"Testable code",
"A testing framework for your language",
View
@@ -1,16 +1,44 @@
---
layout: main
layout: homepage
---
# Digital Contracting Cookbook
The goal of the digital contracting cookbook is to provide agencies with information and suggestions about how to acquire digital services, based on the authors' experience. The cookbook is not a "how-to," in the sense that agencies' requirements are different and there are multiple ways to achieve success.
<a class="skipnav" href="#main-content">Skip main navigation</a>
## Contents
<header role="banner">
{% for recipe in site.data.recipes order:ascending%}
* [{{recipe.title}}]({{site.baseurl}}/recipes/{{recipe.basename}}/)
{% endfor %}
<div class="usa-disclaimer">
<div class="usa-grid">
<span class="usa-disclaimer-official">
<img class="usa-flag_icon" alt="U.S. flag signifying that this is a United States federal government website" src="{{ site.baseurl }}/assets/img/us_flag_small.png">
An official website of the United States government
</span>
<span class="usa-disclaimer-stage">This site is currently in alpha. <a href="https://18f.gsa.gov/dashboard/stages/#alpha">Learn more.</a></span>
</div>
</div>
## How to use
<section class="usa-banner">
<div class="usa-grid">
<nav>
<a class="usa-banner-link-top" href="{{ site.repos[0].url }}">View on GitHub</a>
</nav>
<div class="usa-banner-content" id="main-content">
<h1>Digital Contracting Cookbook</h1>
<h2 class="usa-font-lead">Like Chef, but for Contracting...</h2>
</div>
</div>
</section>
## How to contribute
</header>
<section class="usa-section">
<div class="usa-grid">
<h2>Introducing the Contracting Cookbook</h2>
<p>The goal of the digital contracting cookbook is to provide agencies with information and suggestions about how to acquire digital services, based on the authors' experience. The cookbook is not a "how-to," in the sense that agencies' requirements are different and there are multiple ways to achieve success.</p>
<h2>Contents</h2>
<ul>
{% for recipe in site.data.recipes order:ascending%}
<li><a href="{{site.baseurl}}/recipes/{{recipe.basename}}/">{{recipe.title}}</a></li>
{% endfor %}
</ul>
</div>
</section>

0 comments on commit c1773f4

Please sign in to comment.