5 files changed, 11 insertions, 11 deletions

diff --git a/content/contributor-workshop.article b/content/contributor-workshop.article
index a0a999d..98521ef 100644
--- a/content/contributor-workshop.article
+++ b/content/contributor-workshop.article
@@ -142,7 +142,7 @@ GitHub vs Geritt terminology, so we had better understanding of the process.
 
 .image contributor-workshop/image10.png
 
-Ok, now it was time to become a **freaking** *Go* **contributor**.
+Ok, now it was time to become a *freaking*Go*contributor*.
 
 To make this more exciting than it already is, the Go team set up a game where
 we could track as a group how many points we could rack up based on the Gerrit
@@ -265,7 +265,7 @@ other functions have (and I could use the practice using Gerrit).
 
 I started looking at `go/src/regexp` to try to find where to add examples and I
 got lost pretty quickly. Lucky for me, [[https://twitter.com/francesc][Francesc]] was around that day. He walked
-me through how all examples are actually in-line tests in a `example_test.go
+me through how all examples are actually in-line tests in a `example_test.go`
 file. They follow the format of test cases followed by "Output" commented out
 and then the answers to the tests. For example:
 
@@ -288,7 +288,7 @@ in my patch. It's going to be open for a bit longer given the additional scope,
 but I think it's worth it on this one.
 
 I can hear your question already: how did I verify it worked? Well it wasn't
-easy to be honest. Running `go test example_test.go -run QuoteMeta -v` won't do
+easy to be honest. Running `go`test`example_test.go`-run`QuoteMeta`-v` won't do
 it since we're working outside of our $GOPATH. I struggled to figure it out
 until [[https://medium.com/@vCabbage/go-testing-standard-library-changes-1e9cbed11339][Kale Blakenship wrote this awesome post on testing in Go]].
 Bookmark this one for later.
diff --git a/content/go-app-engine-sdk-155-released.article b/content/go-app-engine-sdk-155-released.article
index e468199..dbe8dd5 100644
--- a/content/go-app-engine-sdk-155-released.article
+++ b/content/go-app-engine-sdk-155-released.article
@@ -20,6 +20,6 @@ The SDK now includes the appengine package source code, so you can use the local
 
 	    /path/to/sdk/godoc appengine/datastore Get
 
-*Important*note:* We have deprecated `api_version` 2. Go apps that use `api_version` 2 will stop working after 16 December 2011. Please update your apps to use api_version 3 before then.
+*Important*note:* We have deprecated `api_version` 2. Go apps that use `api_version` 2 will stop working after 16 December 2011. Please update your apps to use `api_version` 3 before then.
 
 See the [[http://code.google.com/p/googleappengine/wiki/SdkForGoReleaseNotes][release notes]] for a full list of changes. Please direct any questions about the new SDK to the [[http://groups.google.com/group/google-appengine-go][Go App Engine discussion group]].
diff --git a/content/go-at-google-io-2011-videos.article b/content/go-at-google-io-2011-videos.article
index 5e339f3..50dc6f2 100644
--- a/content/go-at-google-io-2011-videos.article
+++ b/content/go-at-google-io-2011-videos.article
@@ -37,6 +37,6 @@ For those that didn’t get one at the conference, we hope to make him available
 
 .iframe //www.youtube.com/embed/7QDVRowyUQA 349 560
 
-(See the [[https://golang.org/doc/talks/io2011/Real_World_Go.pdf ][presentation slides]].)
+(See the [[https://golang.org/doc/talks/io2011/Real_World_Go.pdf][presentation slides]].)
 
 Thanks to everyone who attended our talks and workshops. We look forward to seeing you again soon!
diff --git a/content/ismmkeynote.article b/content/ismmkeynote.article
index 2cd3735..00ef826 100644
--- a/content/ismmkeynote.article
+++ b/content/ismmkeynote.article
@@ -431,7 +431,7 @@ I will refrain from speculating on global market forces in the memory industry b
 
 Long term, it is our belief that memory pricing will drop at a rate that is much faster than CPU pricing.
 
-(Sources [[https://hblok.net/blog/&sa=D&ust=1531164842662000][https://hblok.net/blog/]] and [[https://hblok.net/storage_data/storage_memory_prices_2005-2017-12.png&sa=D&ust=1531164842662000">][https://hblok.net/storage_data/storage_memory_prices_2005-2017-12.png]])
+(Sources [[https://hblok.net/blog/][https://hblok.net/blog/]] and [[https://hblok.net/storage_data/storage_memory_prices_2005-2017-12.png][https://hblok.net/storage_data/storage_memory_prices_2005-2017-12.png]])
 
 .image ismmkeynote/image37.png
 
diff --git a/content/why-generics.article b/content/why-generics.article
index 1881e77..c972550 100644
--- a/content/why-generics.article
+++ b/content/why-generics.article
@@ -288,13 +288,13 @@ We want to do the same with generics.
 To make this more concrete I’m going to list a few guidelines we
 should follow.
 
-*** Minimize new concepts
+** Minimize new concepts
 
 We should add as few new concepts to the language as possible.
 That means a minimum of new syntax and a minimum of new keywords and
 other names.
 
-*** Complexity falls on the writer of generic code, not the user
+** Complexity falls on the writer of generic code, not the user
 
 As much as possible the complexity should fall on the programmer
 writing the generic package.
@@ -304,7 +304,7 @@ natural way, and it means that any errors in using a generic package
 should be reported in a way that is easy to understand and to fix.
 It should also be easy to debug calls into generic code.
 
-*** Writer and user can work independently
+** Writer and user can work independently
 
 Similarly, we should make it easy to separate the concerns of the
 writer of the generic code and its user, so that they can develop their
@@ -315,7 +315,7 @@ have to worry.
 This sounds obvious, but it's not true of generics in every other
 programming language.
 
-*** Short build times, fast execution times
+** Short build times, fast execution times
 
 Naturally, as much as possible, we want to keep the short build times
 and fast execution time that Go gives us today.
@@ -323,7 +323,7 @@ Generics tend to introduce a tradeoff between fast builds and fast
 execution.
 As much as possible, we want both.
 
-*** Preserve clarity and simplicity of Go
+** Preserve clarity and simplicity of Go
 
 Most importantly, Go today is a simple language.
 Go programs are usually clear and easy to understand.