Fix syntax declaration in code blocks

content/1201-the-power-of-applescript.md

@@ -15,8 +15,7 @@ All in all, the script was certainly not pretty, but it did the job. I didn't no
 
 If you want to use the script to rename to your own tracks (or just to examine my shoddily thrown together code), here is the source code; to use the script, copy it into AppleScript Editor, select the tracks in iTunes, and run it.
 
-```
-#!applescript
+```applescript
 tell application "iTunes"
 	set sel to selection
 	if sel is not {} then

content/1302-hosting-with-github-pages.md

@@ -15,8 +15,7 @@ While I use [GitHub for Mac](http://mac.github.com) to manage the repository for
 
 To achieve this, the script runs the following code after the `pelican` command generates the static site files.
 
-```
-#!bash
+```bash
 cd $sourceDirectory
 commitHash=$(git rev-parse HEAD)
 cd $outputDirectory

content/1303-styling-code-blocks-using-pelican.md

@@ -30,8 +30,7 @@ Following this, the line numbering is styled by modifying the `linenos` class. T
 
 The horizontal margins of the `codehilite` class, which controls the code itself, are increased to add spacing between the code snippets and the line numbers.
 
-```
-#!css
+```css
 .linenos {
 	border-right: 1px solid #d9d9d9;
 	background: #eee;

content/1401-on-programming-and-turtles.md

@@ -19,8 +19,7 @@ The terminology used in ComputerCraft is an obvious allusion to the programming
 
 The first major Turtle program that I wrote was a branch mining script. My goal was to write a program that a swarm of Turtles could execute simultaneously to excavate an area for ores. I tend to be meticulous about following patterns when I mine, and when branch mining, this entails digging tunnels with torches every eight blocks. Here is a very basic Turtle script with this functionality.
 
-```
-#!lua
+```lua
 function miningIteration()
   turtle.dig() -- digs the block in front
   turtle.forward() -- moves forward
@@ -43,8 +42,7 @@ The function `miningIteration()` instructs the Turtle to dig the block in front
 
 There is a simple enough fix. The [Turtle API][16] contains functions that allow a Turtle to detect if there is a block in front of, above, or below itself. An improvement to the Turtle would be to detect if there is a block in front of the Turtle and if so, continue digging in front until it there is no block in front. To deal with overhead gravel, the same approach can be taken but by detecting blocks above the Turtle rather than in front of it. Here is the function rewritten to use these detection functions instead of movement functions.
 
-```
-#!lua
+```lua
 function miningIteration()
   while turtle.detect() do turtle.dig() end
   turtle.forward()
@@ -56,8 +54,7 @@ However, this function is still flawed, though the cause of the problem may not
 
 If a Turtle were to execute the current version of `miningIteration()`, it would quickly become apparent that the Turtle still has problems with gravel. If it encountered a column of gravel above itself, it would move forward during the time that the gravel block above itself is was still falling, leaving a pillar of gravel in the middle of the branch mine. The reason for this is that directly after the Turtle finishes executing `turtle.digUp()`, the gravel block is still falling; therefore, `turtle.detectUp()` returns `false`. This causes the Turtle to continue mining instead of properly stopping to mine the gravel above it. This can be solved by pausing the script for just the right amount of time so that it can detect gravel after it had fallen. This timing turned out to be 0.2 seconds, so adding `sleep(0.2)` after the digging functions forces the Turtle to halt for a brief period of time, mining gravel correctly.
 
-```
-#!lua
+```lua
 function miningIteration()
   while turtle.detect() do
     turtle.dig()
@@ -75,8 +72,7 @@ Another interesting behaviour that needed to be debugged was directional-based.
 
 With regards to torch placement, this directional behaviour means that mining in the northwards and southwards direction requires no special treatment. In the remaining two directions, the torch will be placed on the block in front of the Turtle, and in the next iteration of mining, it will get mined along with the block it is attached to. On its own, ComputerCraft does not provide a way for Turtles to automatically determine what direction they are facing (additional mods can add additional types of Turtles to the game). Utilizing ComputerCraft's [GPS API][18] to determine the axis along which a Turtle is travelling would be the only way to add this functionality. As I do not have any GPS infrastructure in my world, I opted to have the Turtle simply prompt the user for the direction that it is facing and store it in the variable `direction`.
 
-```
-#!lua
+```lua
 while true do
   for i = 1, 8 do miningIteration() end
   if direction == 1 or direction == 3 then

content/1402-deploying-pelican-sites-using-travis-ci.md

@@ -16,23 +16,20 @@ One of the issues that I ran into in the process of setting this up was installi
 
 Since I liked some of the features that I had previously included in my site generation Bash script, I rewrote Andrea's `deploy.sh` script to work similarly to my existing workflow. The entirety of the file can be found [in the GitHub repository](https://github.com/iKevinY/iKevinY.github.io/blob/src/generate.sh) of my website's source. My rewritten script grabs the hash and message of the most recent commit to the source branch:
 
-```
-#!bash
+```bash
 commitHash=`git rev-parse HEAD`
 commitMessage=`git log -1 --pretty=%B`
 ```
 
 These variables are used during the `git commit` command to create a descriptive commit message. The commit message in the source branch is used as the first line of the commit message, and the commit hash and Travis build number are included as the extended part of the commit message:
 
-```
-#!bash
+```bash
 git commit -m "$commitMessage" -m "Generated by commit $commitHash; pushed by Travis build $TRAVIS_BUILD_NUMBER."
 ```
 
 There are a few minor changes I made to the `rsync` and `git` commands of Andrea's script as well. Within the `rsync` command, I removed the asterisk from the source directory and added the `--delete` flag to instruct the script to delete files in the destination directory that are not present in the source directory. Simply adding the `--delete` flag to the version of the command present in Andrea's script will not affect the command as a result of the to the wildcard search caused by the asterisk:
 
-```
-#!bash
+```bash
 rsync -r --exclude=.git --delete ../$PELICAN_OUTPUT_FOLDER/ ./
 ```
 

content/1501-on-git-and-github-flow.md

@@ -48,7 +48,6 @@ $ git rebase -i HEAD~n  # rebase the last n commits
 The `-i` flag stands for *interactive*. Upon executing the command, your `$EDITOR` of choice will open with a list of commits from least recent to most recent preceded by the word "pick":
 
 ```
-#!text
 pick a5b977a Ensure all expected resource files exist
 pick f08e801 Add problems 311–320
 pick 969f9e5 Update tests to ensure resource correspondence
@@ -63,7 +62,6 @@ Below the list of commits are some instructions about rebasing, including the av
 Typically, a project maintainer might ask for you to squash your pull request. What this actually involves doing is rebasing and using the "squash" command to turn multiple commits into just one or a couple logical commits. For example, if you wanted to turn the three commits listed above into one larger commit, you would edit the file to look like the following:
 
 ```
-#!text
 pick a5b977a Ensure all expected resource files exist
 squash f08e801 Add problems 311–320
 squash 969f9e5 Update tests to ensure resource correspondence
@@ -77,8 +75,7 @@ I mentioned before that rebasing should only be done with local changes that hav
 
 After forking the project on GitHub, the typical GitHub workflow might look something like this:
 
-```
-#!sh
+```sh
 git clone https://github.com/YOUR_GITHUB_USERNAME/PROJECT_NAME.git
 cd PROJECT_NAME
 git branch my-feature

content/1701-breaking-the-engima-code-with-rust.md

@@ -73,8 +73,7 @@ The bulk of `ultra`'s decryption algorithm involves iterating over Enigma settin
 
 Using the amazing [Rayon](https://github.com/nikomatsakis/rayon) data parallelism library, many Rust iterators can be parallelized nearly effortlessly. With `ultra`, I essentially just needed to import Rayon's prelude and add a couple of calls to `into_par_iter()`. (I also had to collect into a vector because the result of `iproduct!` can't be directly transformed into a parallel iterator.)
 
-```
-#!rust
+```rust
 use rayon::prelude::*;
 
 let (rotor, key) = iproduct!(rotors.iter(), keys.iter())