-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
1011 lines (940 loc) · 99.6 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html>
<head>
<meta charset='utf-8'>
<meta http-equiv='X-UA-Compatible' content='IE=edge,chrome=1'>
<title>Aaron K. Murray's Blog on software, dev life, and the Internet</title>
<meta name='description' content="AaronKMurray.com is a blog about software technology, developer life, and the Internet.">
<meta name='author' content='Aaron K. Murray, akmurray@gmail.com, @aaronkmurray'>
<meta name='viewport' content='width=device-width'>
<link rel='icon' href='favicon.png' type='image/png'>
<link rel='stylesheet' href='css/blog.css'>
<link rel='stylesheet' href='css/blog-logo.css'>
<script type="text/javascript" src="js/prototype-extensions.js"></script>
<script type="text/javascript" src="js/akm-blog.js"></script>
</head>
<body>
<div id='wrapper-body'>
<div id='wrapper-site-header'>
<span class='title'>Aaron K. Murray's Blog on software technology, developer life, and the Internet.</span>
<div id='wrapper-site-header-icons'>
<a href='http://aaronkmurray.com/feeds/feed-rss.xml' target="_blank" title='Subscribe via RSS'><img src='img/blog/icons/icon-rss-32.png' alt='RSS icon'></a>
<a href='https://twitter.com/aaronkmurray' target="_blank" title='Follow me on Twitter @aaronkmurray'><img src='img/blog/icons/icon-twitter-32.png' alt='Twitter icon'></a>
<a href='https://github.com/akmurray' target="_blank" title='View the code for this site on GitHub'><img src='img/blog/icons/icon-github-32.png' alt='GitHub icon'></a>
</div>
</div>
<div id='wrapper-blog-posts'>
<article class='blog-post' id='blog-post-19'>
<div class='blog-post-header'>
<span>Post 19: Fun With A CSS3 Cube</span>
<span class='commit-link'><a href='#' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>In this post I will show you how I did the "3D" CSS cube for my logo. The <a href='https://github.com/akmurray/aaronkmurray-blog/commit/721fc83fad549ba5b27174b7743496fb7e66685d' target="_blank">code for the changes is on GitHub</a> (as usual).
<h3>Site Logo represented as a 3D Cube using CSS3 Transforms</h3>
<p>I won't do a full write-up because there is already <a href='http://desandro.github.com/3dtransforms/docs/cube.html' target="_blank">a nice series of CSS 3D Transforms articles</a> written by <a href='http://desandro.com/' target="_blank">desandro</a>. If you are interested, you should read the article for full details on how to do it yourself.
<p>The summary of interesting bits for how I implemented the logo cube is:
<ul>
<li>HTML: Create a wrapper DIV that will represent the "cube"</li>
<li>HTML: Create 6 DOM Elements inside the wrapper that will represent the 6 sides/faces of the cube</li>
<li><script src="https://gist.github.com/3811888.js"> </script></li>
<li>CSS: <a href='https://github.com/akmurray/aaronkmurray-blog/blob/master/css/blog-logo.css' target="_blank">Style the cube for size and 3D transform</a></li>
<li>JS: After the page loads, set up a timer that will rotate the cube every few seconds</li>
<li><script src="https://gist.github.com/3811934.js"> </script></li>
</ul>
<h3>Fallback when browser doesn't support CSS3 Transforms</h3>
<p>Because having a rotating 3D cube for my logo isn't "critical" for this site, I didn't concern myself with having the same experience for all browsers. In this case, browsers that don't support CSS3 Transforms will not show the 3D rotation. They will simply show the "last" image in the stack of "sides", which will result in a single static logo being displayed.
<p>Currently there are two ways of viewing this concept: <dfn>Graceful Degradation</dfn> and <dfn>Progressive Enhancement</dfn>.
<ol>
<li><dfn>Graceful Degradation</dfn> means that if a feature isn't supported, and acceptable fallback would occur.</li>
<li><dfn>Progressive Enhancement</dfn> is the opposite way of viewing the same situation. A basic experience is defined, and when possible, enhancements to that experience will be provided based on browser support.</li>
</ol>
<p>The differences are subtle, but meaningful.
<ul>
<li><dfn>Progressive Enhancement</dfn> implies that all basic functionality will exist, and then extras will be added on to make the experience better. Example: The logo for this site will be a 2D image, unless the browser supports a 3D rendering via CSS.</li>
<li><dfn>Graceful Degradation</dfn> typically means that when failure occurs, it doesn't completely kill the experience, but that experience may not be the same. The primary example of this is the use of a text message to the user when Adobe's Flash plugin is not installed/available, instead of providing an alternative way to see that content.</li>
</ul>
<p>It's up to you to choose when features are "critical" and when they are simply icing on the cake.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>css3</span>, <span class='post-tag'>cube</span>, <span class='post-tag'>logo</span>, <span class='post-tag'>progressive enhancement</span>, <span class='post-tag'>graceful degradation</span></span>
<span class='post-timestamp'>Posted on October 1, 2012 @ 11:05AM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-19.png' target="_blank"><img src='img/blog/screenshots/post-19-thumb-100.png' alt='Screenshot of site after post #19'></a></span>
</div>
<div class='blog-post-guid'>aea98599-7cb9-4cc4-ad4e-81d7b4c0c627</div>
</article>
<article class='blog-post' id='blog-post-18'>
<div class='blog-post-header'>
<span>Post 18: SEO Part 2/4: Optimizing Code Tags For SEO</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/9c1566a5addefa03afe411bb3be70b45b2d17284' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p><em>As I mentioned in <a href='#blog-post-10'>Post 10: The SEO Plan</a>, this post is the second in a 4-part series on SEO written by guest author <a href='https://twitter.com/slivengood' target="_blank">Shawn Livengood</a> who runs the blog <a href='http://ppcwithoutpity.com/' target="_blank">ppcwithoutpity.com</a>. If you haven't already, check out <a href='#blog-post-14'>Part 1: Getting Indexed</a></em>. And after you finish reading this post, have a look at the code changes for this post in GitHub to see Shawn's suggestions at work on this site, as well as some <a href='http://www.w3schools.com/html5/html5_reference.asp' target="_blank">html tag</a> changes to move towards cleaner, <a href='http://en.wikipedia.org/wiki/Semantic_HTML' target="_blank">semantic markup</a>.
<div class='guest-post-content'>
<h3>SEO Part 2: Optimizing Code Tags For SEO</h3>
<p>It's a common misconception that there are some magical code tweaks that you can make to your site to "do" SEO. Unfortunately, this is not the case. About ten or fifteen years ago, when search engines were just starting to achieve mainstream popularity, there were a lot of secret tweaks you could do to fool search engines into thinking your spam site was the most relevant page for a specific search query. Fortunately for search engine users, search engines have closed many of these loopholes, and the effect of on-site signals to determine keyword relevance have been somewhat diminished.
<p>However, they have not been eliminated entirely. There are still a few code tags that you can enter keywords into in order to influence search engine ranking. Sometimes, if you're targeting a key term with little or no competition, you can even reach a #1 rank through code optimization alone. Let's take a look at some of the code tags that still influence SEO rank.
<h3>"META" Tags</h3>
<p><code><meta></code> tags appear in the <code><head></code> section of each page on your website, and provide metadata to browsers and search engines about what your page is about. There are lots of different <code><meta></code> tags, but there are only two that have much bearing on SEO.
<h3><Title></h3>
<p>The <code><title></code> tag defines your page's title, and most browsers render the title as the text in your browser tab that labels the site. It's also the text that appears in the hyperlink on a search engine results page (SERP). In the code, it looks a little something like this:
<p><code><title>PPC Without Pity - A PPC Marketing Blog From A Merciless Perspective</title></code>
<p>Different search engines and browsers have different character limits for the title tag (or at least, limits on what text they display). This limit varies between 65 to 72 characters. So it's best to keep your <code><title></code> tag length around 60 characters or less.
<p>You can insert keywords into your title tag. These keywords seem to have a powerful influence on ranking. In fact, optimizing your <code><title></code> tag for targeted keywords is probably the easiest thing you can do to your site that will have a distinct SEO impact. But, that doesn't mean you should just cram a mess of keywords into your title tag. Pick one or two phrases you want to target, then add your site's title after that (or if it's your home page, put your site's title first).
<h3><META> Description</h3>
<p>The <code><meta></code> description tag also appears in your site's <code><head></code> section. This tag provides the words that appear below your site's hyperlinked title in the SERPs. Or at least, it does most of the time - if your <code><meta></code> description is spammy or nonexistent, the search engines may replace that block of text with a different block of text that appears within your page. A <code><meta></code> description tag looks like this in the code:
<p><code><meta name="description" content="A PPC blog dedicated to pay per click advertising, Google Adwords, Yahoo Search Marketing, MSN AdCenter, and other pay per click advertising formats and accounts." /></code>
<p><code><meta></code> description doesn't have any direct bearing on your search engine ranking. That particular loophole was closed years ago. But, since the <code><meta></code> description appears on the SERPs, it will influence whether or not a user clicks on your site. If you have a really appealing description tag, you may end up getting more clicks than other sites on the results page with an irrelevant description. Treat your <code><meta></code> description as ad copy to entice a user to click on your result.
<p>Like the <code><meta></code> title, this tag has varying character limits depending on the search engine. But if you keep your <code><meta></code> description below 150 characters, you should be good.
<h3><META> Keywords</h3>
<p>Another tag that appears in the <code><head></code> section, but this one has absolutely no effect on anything. But, it's worth mentioning for that fact. This meta tag was highly abused back in the day, so search engines have disregarded it entirely. If someone is trying to give you SEO advice by telling you to optimize for <code><meta></code> keywords, it's probably a good indicator that they don't know what they're talking about.
<h3>Heading Tags (H1, H2, H3, etc.)</h3>
<p>Heading tags were used more frequently in pre-CSS web development to segment content sections. But now that CSS does that trick, heading tags are somewhat obsolete. Still, there is some evidence that search engines use keywords within H1, H2, and occasionally H3 tags to determine ranking. H1 tags pass the most influence, and H2s pass a little. So if you're using H1 tags, it's a good idea to give some thought to which keywords you use in them.
<h3>Image Alt Tags</h3>
<p>When you create an image, you have an option to create an "alt" attribute to append a text description to the image. It looks like this:
<p><code><img src="http://ppcwithoutpity.com/wp-content/uploads/2012/09/adwords-seller-ratings-example.jpg" alt="adwords seller ratings example" width="224" height="103" class="aligncenter size-full wp-image-943" /></code>
<p>Alt attributes were created to aid in screen-reading programs for blind web users. Having a picture doesn't really help describe anything if you're unable to see it. But guess who else can't see images to tell what they're about? Search engines! Search engine spiders use the text in the alt attribute to determine the topic of your image. If you put some keywords within your alt attribute, then it could help those keywords rank for the page they appear on.
<h3>A Final Note On Keyword Content</h3>
<p>Including keywords within these code tags is important, but let's not forget the most important place to put your keywords: your content. If you want to rank well for a keyword, it needs to appear within your content, preferably somewhere within the first paragraph or so. But, that doesn't give you a license to just pump your page content full of the same keyword. A good sniff test is to have someone else read your content and ask them if any keyword appears to be repeated too often. You could potentially be penalized for having a spammy site if your site content seems stuffed full of keywords, so you really need to straddle that fine line between using your targeted keywords, but not using them unnaturally.
<p>-<a href='https://twitter.com/slivengood' target="_blank">Shawn Livengood</a>
</div>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>seo</span>, <span class='post-tag'>meta</span>, <span class='post-tag'>tags</span></span>
<span class='post-timestamp'>Posted on September 24, 2012 @ 3:04PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-18.png' target="_blank"><img src='img/blog/screenshots/post-18-thumb-100.png' alt='Screenshot of site after post #18'></a></span>
</div>
<div class='blog-post-guid'>f403007e-6f72-4364-8539-18e1adbd6508</div>
</article>
<article class='blog-post' id='blog-post-17'>
<div class='blog-post-header'>
<span>Post 17: First Month Retrospective</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/05bb0715f65389b4c173b20eea40a989fbb5e41a' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>I'm a big fan of postmortems, and find myself reading lots of them from sites like <a href='http://gamasutra.com/search/index.php?search_text=postmortem' target="_blank">Gamasutra.com</a>.
<p>The great thing about doing a postmortem is that it helps re-enforce and solidify the learning experiences from a project while they are still fresh.
<p>It has been a month since I started this blog, so I figured that a look back at the project was in order.
<h3>What Went Right</h3>
<ul>
<li>Lots of posts. I was worried that I wouldn't find enough minutes in each day to construct a decent post.</li>
<li>Variety of posts. I've covered various topics, from entry-level HTML and CSS, to build scripts and tools.</li>
<li>RSS Feed. Not getting one up quickly was my biggest fear when doing a blog project from scratch.</li>
</ul>
<h3>What Went Wrong</h3>
<ul>
<li>RSS Feed. The intial feed had bugs that spammed all posts out as new posts each time I did an update.</li>
<li>Not enough pictures. Looking back at the posts, many of them are huge walls of text.</li>
<li>Build/Commit/Build process. I still have to do 2 GitHub Commits for each post because each post has a link to it's own commit. Still trying to figure that one out.</li>
</ul>
<h3>Frustrations</h3>
<p>As much fun as I am having with this project, there are still many frustrations and things that "feel wrong" every time I do them.
<ul>
<li>Not having a tradition database feels yucky/scary</li>
<li>Copying and Pasting my post template with each post feels wrong and is prone to error</li>
<li>Not using code that I've already written to acheive things that I want to do feels wasteful</li>
<li>Writing everything from scratch feels tedious (yet liberating) at times</li>
<li>My Build/Release process still has a couple manual steps</li>
</ul>
<h3>Realizations</h3>
<ul>
<li>Different is okay. I was so used to doing sites a certain way with a wealth of frameworks that I've built up and leveraged over the years, it was scary and foreign to go back to a single HTML page as a starting point. Now I am embracing the process. With each post I challenge myself to achieve the intended end result in a way that I have not done before.</li>
<li>Database != DBMS. Thinking about the term "database" without meaning mySQL, SQL Server, or Raven is really odd. Currently, the database for this site is <a href='https://github.com/akmurray/aaronkmurray-blog/blob/master/index.html' target="_blank">index.html</a>. That is a new paradigm of thinking for me, and it has led to some radical thoughts that I plan on exploring in the future.</li>
<li>New process is hard. It actually isn't the process that is difficult as much as challenging my brain to be willing to do things that I've done a dozen times in a new and different way.</li>
</ul>
<h3>What Is Next?</h3>
<p>This is the constant question. There are many things that I have listed out in my project notes. Here is a quick sample of things on my short-list:
<ul>
<li>Tech: use a CDN</li>
<li>Tech: js and css minification, bundling, versioning, and debugging</li>
<li>Tech: css sprites/images</li>
<li>Tech: html minification</li>
<li>Tech: url-rewriting</li>
<li>Tech: automated testing</li>
<li>Tech: reporting</li>
<li>Tech: figure out what "database" means</li>
<li>Tech: automatic seo analytics capture</li>
<li>Tech: server-side rendering and client-side MVC</li>
<li>Feature: tag cloud</li>
<li>Feature: permalinks</li>
<li>Feature: post paging</li>
<li>Feature: post comments</li>
<li>Feature: social integrations</li>
<li>Feature: decent UI design</li>
</ul>
<p>If there are other things that you'd like to see, <a href='https://twitter.com/aaronkmurray' target="_blank">hit me up on Twitter</a>.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>postmortem</span>, <span class='post-tag'>retrospective</span></span>
<span class='post-timestamp'>Posted on September 21, 2012 @ 3:20PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-17.png' target="_blank"><img src='img/blog/screenshots/post-17-thumb-100.png' alt='Screenshot of site after post #17'></a></span>
</div>
<div class='blog-post-guid'>8197c362-a697-414c-bbe2-72d6247303bc</div>
</article>
<article class='blog-post' id='blog-post-16'>
<div class='blog-post-header'>
<span>Post 16: HTML Markup Cleanup</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/4d9163e225d90e52b78cc6219efa6fd1c5ad1a8e' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>This post is a little bit of housekeeping and HTML fundamentals. It will touch on a few of the "smaller" questions that come up related to writing HTML, and then show how to use an automated tool at build time to get a report on the basic structure of our HTML (look for errors, etc.)
<h3>A micro-history of HTML</h3>
<p>Back in the old days, browsers were fighting to provide the best experience possible as we were discovering the possibilities of the Internet.
<p>At their core, browser are essentially fancy text parsers. They get HTML from a server, and then try to interpret that text and turn it into a nice picture for a human.
<p>It sounds simple enough, but instantly it was troublesome. As it turns out, humans aren't perfect when it comes to creating nested hierarchies of nodes and text. And back then, many sites were hand-made similarly to how this blog is currently being developed. Despite our best efforts, we humans still get it wrong.
<p>For browsers, they needed to not only be great at parsing HTML, but they had to be even better at deriving the author's intention in the midst of the author's own HTML mistakes. This was part of the reason for all of the old nasty doctype declarations (see next section). The goal was to give the browser a hint at what the author intended.
<h3>DOCTYPE</h3>
<p>Let's start from the top: <a href='http://www.w3schools.com/tags/tag_doctype.asp' target="_blank">doctype</a>.
<p>Doctype is a special tag that basically tells the browser what type of document that it should expect to parse. As such, it has to be the first element of a page.
<p>Here is the modern example: <code><!doctype html></code>
<p>There are all sort of different doctypes out there, but the skinny is: if you are making a new site, or you are fortunate enough to no be concerned with supporting ancient browsers, then the doctype example from above is all you need to use. Done. Simple.
<p>If you live in the e-Commerce world, work on intranet apps, or have an affinity for providing support to folks who still use Netscape 4.7, then you have a decision to make.
<p>I won't go into the details here, but it's likely that you'll be using <code>HTML 4.01 Transitional</code> or <code>HTML 4.01 Frameset</code>.
<p>Well, just as authors can make mistakes in the markup, they can also make mistakes when choosing a doctype. Furthermore, most pages on large sites are actually generated on the fly by combining smaller chunks of html into one large page. This makes it especially hard to determine which doctype should be used. The code that chooses the doctype may be aggregating HTML from a source without knowing if that HTML is going to use FRAMESETS. Ugh.
<p>The old intention was noble, but ultimately flawed. So now we just go back to basics, and tell the browser that it should expect HTML.
<h3>XHTML vs HTML</h3>
<p>The first thing you learn when you start researching (old) doctypes is that in addition to HTML, there is an option for XHTML.
<p>To put it simply, XHTML is strictly-written HTML. It doesn't allow for mistakes. It removes the interpretation part from the lenient HTML structure parsing that browsers do.
<p>Again, this was originally intended to combat the wild-west, poorly written HTML that originally dominated the Internet. The moral of this story is: chances are likely that you will never have to know or care about XHTML. Be thankful for that.
<h3>Tag and Attribute Names: uppercase vs lowercase</h3>
<p>Easy: doesn't matter. UPPER CASE has a way of crying out for attention. Typically when I am reading HTML I am more interested in the tag attribute values as opposed to the tag names and attribute. Because of this, I prefer lowercase. These are functionally equivalent:
<ul>
<li><code><!doctype html></code></li>
<li><code><!DOCTYPE HTML></code></li>
</ul>
<h3>DOM Element Identification: "<code>id</code>" vs "<code>name</code>"</h3>
<p>Both <code>id</code> and <code>name</code> are attributes for DOM elements that allow you to identify certain nodes. There are differences, but this guideline will take you a long way: use <code>id</code> instead of <code>name</code> to uniquely identify elements.
<p>When should you use <code>name</code> then?
<ul>
<li>Only on <code>form</code> elements that you want to submit to a server</li>
<li>Only on the tags: <code>a, form, iframe, img, map, input, select, textarea</code></li>
<li>Example: <code><input type='text' id='txtAddress' name='txtAddress' ... /></code></li>
</ul>
<p>It is okay/advisable to also use the <code>id</code> attribute whenever using the <code>name</code> attribute. My standard mode of operating is to use the <code>id</code> attribute always, and then additionally use the <code>name</code> attribute on <code>form input</code> fields.
<h3>Attribute values: with or without quotes?</h3>
<p>Simply put: use quotes if the attribute <code>value</code> has a space in it. If the value comes from a database or other location, then use quotes and make sure to escape any quotes that may appear in that value by using <code>&#39;</code>for single quotes and <code>&quot;</code> for double quotes.
<p>Examples:
<ul>
<li>Right: <code><input type='text' value='Aaron<strong>&#39;</strong>s House' name='txtPartyLocation' ... /></code></li>
<li>Wrong: <code><input type='text' value='Aaron<strong>'</strong>s House' name='txtPartyLocation' ... /></code></li>
<li>Right: <code><input type="text" value="The <strong>&quot;</strong>Good<strong>&quot;</strong> Son" name="txtNickname" ... /></code></li>
<li>Wrong: <code><input type="text" value="The <strong>"</strong>Good<strong>"</strong> Son" name="txtNickname" ... /></code></li>
</ul>
<h3>Attribute values: Single quotes vs Double quotes</h3>
<p>Short answer: either. Individual style preference. Functionally they are the same. If you are working in a big project that uses double quotes, use double quotes. And vice versa.
<p>Personally, I am conflicted. I prefer single quotes because it "cuts down on the visual noise" when I'm looking at HTML and javascript, but the flipside is that I write a lot of C# code and <code>strings</code> in C# are wrapped in double quotes. These days I find myself using single quotes most of the time.
<h3>Tools to help</h3>
<p>Above I mentioned that web browsers work by parsing text/HTML and turning that into a visual that humans can understand more easily. There are tools that we can use to pre-parse the HTML and then warn us of the glaring structural errors. For this example, I'll show a tool called <a href='https://github.com/w3c/tidy-html5' target="_blank">html-tidy5</a> that can be run as part of our build process.
<p>There are also <a href='http://lint.brihten.com/html/report?u=http%3A//aaronkmurray.com&s=0100110#' target="_blank">online tools</a> that you can play with to see example results.
<p>I added tidy as the first step in the <a href='https://github.com/akmurray/aaronkmurray-blog-tools/blob/master/build/build-aaronkmurray-site.bat' target="_blank">build script for this site</a>. If it finds errors or warnings when it runs, it will cancel the build and open notepad to show a list of problems. Those can then be fixed, and the build can be run again.
<p>Here is a sample of what html tidy found on this page:
<ul>
<li>Illegal closing tag <code></span></code> for <code><li></code></li>
<li>A quotation error in my meta name=description tag after refactoring double quotes to single quotes</li>
<li>target='_target' instead of target='_blank'</li>
<li>missing alt tags on images</li>
</ul>
<p>I was able to quickly go back and make edits to correct the bugs that I had created. I did have to make a change to the automatic timestamp HTML because tidy flags empty <code>span</code> nodes as warnings. The choice was either to ignore warnings altogether, which would leave me vulnerable to dozens of other warnings that it found, or change my process to stub out a value that was easy to detect. I chose the latter, so now my empty timestamp stubs have a question mark in them, and look like:
<ul>
<li><code>>span class='post-timestamp'<?>/span<</code></li>
</ul>
<p>This new process is a simple way to ensure that I maintain a decent quality of my code as the project gets bigger.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>html</span>, <span class='post-tag'>tidy</span>, <span class='post-tag'>doctype</span>, <span class='post-tag'>xhtml</span>, <span class='post-tag'>attributes</span></span>
<span class='post-timestamp'>Posted on September 21, 2012 @ 3:25PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-16.png' target="_blank"><img src='img/blog/screenshots/post-16-thumb-100.png' alt='Screenshot of site after post #16'></a></span>
</div>
<div class='blog-post-guid'>e19b213c-4e59-4c4d-bcc7-33973d0576f5</div>
</article>
<article class='blog-post' id='blog-post-15'>
<div class='blog-post-header'>
<span>Post 15: CSS Includes</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/7d59ad24082cc8f8b43b873e22ec2cd031ea9063' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Back to basics. I've blogged a couple of times already about the importance of reducing the amount of data that has to be downloaded. Some of you have noticed that up until now, the CSS styles for this blog were still imbedded in the HTML markup.
<p>First, let me explain why the seemingly odd order. There was less that 2KB of CSS in the page, as compared to hundreds of KB in images. I also wanted to have a history right in the index.html for a while so that it was easily apparent to learners looking through the GitHub commit history which CSS changes were causing the visual differences with the first few posts.
<p>In the big picture of site performance, including CSS styles in separate files provides the following benefits:
<ul>
<li>The styles can be used by different pages on the site (code reuse)</li>
<li>The CSS files can be cached by the browser so that they do not have to be re-downloaded with each page view</li>
<li>The CSS files can be served from a different server in your network, or even a different network entirely (like a global <a href='http://en.wikipedia.org/wiki/Content_delivery_network' target="_blank">CDN</a>)</li>
<li>The CSS files can be compressed, even if your HTML content is not</li>
</ul>
<p>The downsides including CSS styles in separate files are:
<ul>
<li>Initial (empty cache) page load (slightly) takes longer with multiple requests</li>
<li>If external files are served from a different domain/subdomain, then there is also an extra (relatively slow-ish) <a href='https://developers.google.com/speed/docs/best-practices/rtt#MinimizeDNSLookups' target="_blank">DNS lookup</a></li>
<li>Browsers need to know when the file was last changed in order to not use outdated/changed files</li>
</ul>
<p>In practice, the upsides outweigh the downsides considerably. So let's get started!
<p>First, start off by making a new text file. I'll call this <code>blog.css</code> for the sake of simplicity and place it in a folder called <code>css</code>. Then simply add some html to the <code><head></code> section let the browser know that it needs to download those styles and use them in the page:
<ul>
<li><code><link rel='stylesheet' href='<a href='css/blog.css' target="_blank">css/blog.css</a>'></code></li>
</ul>
<p>Final note: the one truly notable downside with external file includes has to do with the browsers caching files and dealing with the scenario where a visitor has been to your site before. In that scenario, browser will nearly always try to use a cached version on the file, but may fail to recognize, for various reasons, that the file has been updated/changed and that it should use the latest version from the server instead of the one that it has saved locally. This can cause users to view your site with the old files, and is usually the reason you hear a first web-debugging step of "clear your cache" or "restart your browser/computer."
<p>The best and most reliable way around this is to put simple version numbers in your actual filenames so that the browser always tries to fetch a file that has changed, but that can be cumbersome to maintain. Example:
<ul>
<li><code><link rel='stylesheet' href='css/blog-version-123.css'></code></li>
</ul>
<p>Other, less ideal, methods include:
<ul>
<li>Include a querystring paramter after the filename that changes with each version: <code><link rel='stylesheet' href='css/blog.css?version=123'></code>
<ol>
<li>Problem: The file won't be automatically cached for you by external/regionally distributed networks/routers/switches.</li>
<li>Problem: The browser isn't guaranteed to actually fetch the new version</li>
</ol>
</li>
<li>Specify a <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9' target="_blank"><code>Cache-Control</code></a> Response header: <code>Cache-Control: max-age=3600, must-revalidate</code>
<ol>
<li>Problem: You need to have a good estimate of how frequently files change to set a "good" <code>max-age</code> value in seconds (or any of the other directive values)</li>
<li>Problem: The browser doesn't always obey these headers for various technical reasons</li>
</ol>
</li>
<li>Specify an <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19' target="_blank"><code>ETag</code></a> Response header: <code>ETag:"1edec-3e3073913b100"</code>
<ol>
<li>Problem: This value needs to change when the contents of the file change</li>
<li>Problem: The browser doesn't always obey these headers for various technical reasons</li>
</ol>
</li>
<li>Specify an <a href='http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21' target="_blank"><code>Expires</code></a> Response header: <code>Expires: Thu, 20 Sep 2012 16:00:00 GMT</code>
<ol>
<li>Problem: You need to have a good estimate of how frequently files change to set a "good" <code>Expires</code> value in GMT date format</li>
<li>Problem: The browser doesn't always obey these headers for various technical reasons</li>
</ol>
</li>
</ul>
<p>In the worst case scenario of my versioned filename approach, the user will refetch the newest version of the file with each page load. In the worst case scenario of the other methods, the user have the wrong version of the file. In a future post, we'll go over some automated ways of handling this situation.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>css</span>, <span class='post-tag'>cdn</span>, <span class='post-tag'>bandwidth</span>, <span class='post-tag'>performance</span></span>
<span class='post-timestamp'>Posted on September 20, 2012 @ 2:00PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-15.png' target="_blank"><img src='img/blog/screenshots/post-15-thumb-100.png' alt='Screenshot of site after post #15'></a></span>
</div>
<div class='blog-post-guid'>1ee21e12-47fb-4d50-9e17-72ab21aab632</div>
</article>
<article class='blog-post' id='blog-post-14'>
<div class='blog-post-header'>
<span>Post 14: SEO Part 1/4: Getting Indexed</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/809680a52837a2f86cac25aa714f61eb7268055c' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p><em>As I mentioned in <a href='#blog-post-10'>Post 10: The SEO Plan</a>, this post is the first in a 4-part series on SEO written by guest author <a href='https://twitter.com/slivengood' target="_blank">Shawn Livengood</a> who runs the blog <a href='http://ppcwithoutpity.com/' target="_blank">ppcwithoutpity.com</a>. </em>
<div class='guest-post-content'>
<h3>SEO Part 1: Getting Indexed</h3>
<p>Before you can start seeing spectacular SEO results on your site, first you have to let the search engines know that your site is there. There are a few ways to go about this:
<ol>
<li>Google Webmaster Tools submission</li>
<li>Bing Webmaster Tools submission</li>
<li>Creating an XML sitemap</li>
<li>Getting a link from an influential, recently-cached site</li>
</ol>
<p>Let's go through the how-to of each one.
<h3>Google Webmaster Tools</h3>
<ol>
<li>Go to <a href='http://www.google.com/webmasters/' target="_blank">google.com/webmasters</a> to create an account.</li>
<li>Once you create an account, click on the "Add A Site" button to add your URL.</li>
<li>After you enter the URL you want to add, you'll be asked to verify that you own the site. You can do this via several different methods: through your domain name provider, uploading an HTML file to your web server, adding a special META tag to your homepage header, or by linking your Google Analytics account. Different sites and hosting configurations have different interactions with each of these verification methods. But, the most reliable (and easiest) method in my experience is the META tag addition.</li>
</ol>
<div class='callout'>
<img src='img/blog/posts/post-14-3-gwt-step-3.jpg' alt='Google Webmaster Tools: Verify Site'>
<span class='citation'>Google Webmaster Tools: Verify Site Ownership Options</span>
</div>
<p>Once your site is verified, you will have access to a set of tools that will help you diagnose SEO issues with your site, track inbound links and search queries, and create ways to help Google index your site. I won't get into all the ins and outs of Google Webmaster Tools here (that would take a whole series of posts), but I do want to cover a few settings that will help get your site indexed initially.
<p>Click on the Configuration section in the navigation, and select "Settings." You have a few options on this page. You can select your geographic target here. This will help Google understand what your local language is in, and which international Google search engines should give your site priority. Also on this page, you can choose a preferred domain. You can state that you prefer your domain with or without "www." This will help prevent duplicate content issues by defining one canonical version of your domain name in Google's system. The third option on this page is to select the crawl rate. If you just added your site, you probably won't have the option to change this just yet. But once you get some traffic, you can return to this page to define a suggested crawl frequency for Google's spiders to re-index your site. Of course, this is just a suggestion to Google - there's no guarantee they'll actually follow your instructions.
<p>In Google Webmaster tools, you can also upload an XML sitemap. You can perform this task in the Optimization > Sitemaps section of your account. We'll go into this a little bit more in the sitemaps part of this post.
<h3>Bing Webmaster Tools</h3>
<p>Bing may not be as popular as Google, but it still gets enough user traffic where it makes sense to have your site indexed by them. Fortunately, they also have a webmaster tools account where you can show Bing how to index your content.
<ol>
<li>Go to <a href='http://www.bing.com/toolbox/webmaster' target="_blank">bing.com/toolbox/webmaster</a></li>
<li>Enter the URL of the site you want to add at the top of the page.</li>
<li>Fill out the form on the next page with your personal information. You can also add a sitemap URL on this form, if you have one.</li>
<li>Once you save your info, your site will appear on your Bing Webmaster Tools dashboard. But, you still need to verify it. Click on the "Verify Now" link next to the site URL.</li>
<li>Bing offers you three verification methods: you can upload a special Bing XML file to your root folder in your hosting account, you can verify via a special META tag on your homepage <code><head></code> section, or you can add a unique CNAME record to your DNS.</li>
</ol>
<div class='callout'>
<img src='img/blog/posts/post-14-10-bing-verify-site-options.jpg' alt='Bing Webmaster Tools: Verify Site Ownership'>
<span class='citation'>Bing Webmaster Tools: Verify Site Ownership Options</span>
</div>
<p>Bing Webmaster Tools also has a lot of options to help your site get crawled. You can submit sitemaps, submit individual URLs, and define the crawl rate of your site. All of these options help your new site become more findable by search engine spiders.
<h3>Creating an XML Sitemap</h3>
<p>As I mentioned above, creating a sitemap is an important part of getting a website crawled by search engine spiders. First, some clarification: just adding a sitemap will not make your site more findable. What a sitemap does is provide a roadmap for crawlers that arrive on your site, helping them find all of the pages within your domain. A crawler has to reach your domain in the first place for a sitemap to help, and uploading that sitemap will not help anything find your domain. But, the sitemap does play an important role in assisting web crawlers with finding all of the obscure, deeply-buried pages within your site. And the more pages on your site that get found, the more pages that have the potential to show up on a web search.
<p>If you have a small (< 500 page) site, you can create a sitemap for free using the tool at <a href='http://www.xml-sitemaps.com/' target="_blank">xml-sitemaps.com</a>. Just follow the instructions on the page and you should be good to go. If you have a larger site, you may need to run a program on your web server to index and create all the entries on the sitemap. Google has a tool for this (in beta, of course) at this URL: <a href='http://code.google.com/p/googlesitemapgenerator/' target="_blank">code.google.com/p/googlesitemapgenerator/</a>. There are also dozens of other tools out there to create sitemaps, so finding an easy way to make one is only a Google search away.
<p>Once you have a sitemap, you'll need to upload it to your web server. It must reside at this address: <em>www.your-site-name-here.com</em>/sitemap.xml. If you have to gzip your sitemap due to size, the URL of <em>www.your-site-name-here.com</em>/sitemap.xml.gz is also acceptable. Whichever URL you go with, make sure to enter this URL in your robots.txt file to ensure that the search engines know where it is. And just to be extra sure, submit that sitemap to both Google Webmaster Tools and Bing Webmaster Tools.
<h3>Getting An Influential Link</h3>
<p>Even after all this work, it may take a while for the search engines to find your site to speed up this process, it helps to get a strong initial link to get the ball rolling. You'll want to get a link from a site that gets cached frequently. If crawlers return to a site frequently to check for new links, the link to your site should be found quickly, meaning that the crawler will reach your site via the link and add it to the search engine's index as soon as the page with your link is cached. Also, you should make sure that the link you get is dofollow - a crawler will not pass through a nofollow link, negating the benefit of indexation.
<p>Getting links isn't exactly easy. But, maybe you have an established site that gets decent search traffic. Or maybe you know a friend who has one. You can even reach out to an influential blogger that you admire and ask them nicely to give you a link to this new project you're working on. Be creative in your linkbuilding, and you will be rewarded.
<p>To check on when a page was last cached by Google, you can use this tool: <a href='http://www.searchenginegenie.com/tools/google-bot-last-accessed-date.php' target="_blank">searchenginegenie.com/tools/google-bot-last-accessed-date.php</a>. Or, the SEOBook toolbar has this functionality within their browser extension. You can download it here: <a href='http://tools.seobook.com/seo-toolbar/' target="_blank">tools.seobook.com/seo-toolbar/</a>. Remember to check the cache date of the page where your link will appear. Homepages tend to get cached pretty frequently, while individual post and category pages do not.
<p>-<a href='https://twitter.com/slivengood' target="_blank">Shawn Livengood</a>
</div>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>seo</span>, <span class='post-tag'>google</span>, <span class='post-tag'>bing</span>, <span class='post-tag'>sitemap</span>, <span class='post-tag'>ppcwithoutpity</span></span>
<span class='post-timestamp'>Posted on September 18, 2012 @ 11:59AM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-14.png' target="_blank"><img src='img/blog/screenshots/post-14-thumb-100.png' alt='Screenshot of site after post #14'></a></span>
</div>
<div class='blog-post-guid'>7559decd-05a3-49f5-ac1b-81248aa6789d</div>
</article>
<article class='blog-post' id='blog-post-13'>
<div class='blog-post-header'>
<span>Post 13: Image Thumbnails</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/266bee8839e36297db1fe4256ff1d3e331712c52' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Way back in <a href='#blog-post-8'>Post 8</a> I mentioned 2 ways to reduce the impact of images on bandwidth. The method I tackled then was to automatically compress the png images in the build script. In this post, I will show you how to further reduce the impact by creating and displaying thumbnails instead of scaling down the original image using HTML (<code><img ... <strong>width=100</strong> /></code>).
<div class='callout'>
<img src='img/blog/posts/post-13-request-payload-before-thumbnails-chart.png' alt='Request payload before thumbnails'>
<span class='citation'>Request payload before using thumbnails (inspected using Firefox, <a href='http://getfirebug.com/' target="_blank">FireBug</a>, and <a href='http://developer.yahoo.com/yslow/' target="_blank">YSlow</a> plugin)</span>
</div>
<p>As you can see from the chart, fully 98% of the data that users have to download from the site is for images. Of those 24 images, 12 were fullsize blog post screenshots, which weighed in at a portly 1.17MB. Those 12 little screenshot previews accounted 77% of the size for the entire page - and that is after we compressed the images to reduce about one-third of the filesize.
<p>I made a sample thumbnail by resizing the image down to 100 pixels wide produced a new preview image that was 90% smaller than the original. The prospect of reducing 77% of the entire request payload by 90% got me excited.
<p>Given that I still despise the copy/paste portion of creating new blog posts, and knowing that I don't want to make it harder on myself to release a blog post, I wanted a solution that was 100% automated. There already exists a <a href='https://github.com/akmurray/aaronkmurray-blog-tools/blob/master/build/build-aaronkmurray-site.bat' target="_blank">build script for this site</a> so I knew that I wanted to tie into that step.
<p>
<script src='https://gist.github.com/3739310.js'> </script>
<p>Notes on the batch file:
<ul>
<li>The <code>FOR</code> loop gets a list of all of the screenshot files that don't have "thumb" in the name</li>
<li><code>SETLOCAL ENABLEDELAYEDEXPANSION</code> is special inside of loops so that variables can be set with each iteration</li>
<li>A new thumbnail file is only created if one does not exist already</li>
<li><code>convert.exe</code> file comes from the free image utility library <a href='http://www.imagemagick.org'>ImageMagick</a></li>
</ul>
<p>The result is that the sum total filesize of the first 12 post thumbnail images is 111KB (a savings of over 1 megabyte). I also removed the <code>width=100</code> attributes from the previews as they are no longer necessary. Not too shabby for a few lines of code added to the build script.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>images</span>, <span class='post-tag'>bandwidth</span>, <span class='post-tag'>batchfile</span>, <span class='post-tag'>build</span>, <span class='post-tag'>tools</span>, <span class='post-tag'>thumbnail</span></span>
<span class='post-timestamp'>Posted on September 17, 2012 @ 2:55PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-13.png' target="_blank"><img src='img/blog/screenshots/post-13-thumb-100.png' alt='Screenshot of site after post #13'></a></span>
</div>
<div class='blog-post-guid'>6bbfc7bf-2561-4cd0-a384-5574f714e51a</div>
</article>
<article class='blog-post' id='blog-post-12'>
<div class='blog-post-header'>
<span>Post 12: Favicon</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/45555907c121025acf277bd2f7200b3b5417a166' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Alrighty. Today's post is simple - but something that is very visible to users. The Favicon.
<p>A Favicon is the little icon that appears in the browser tab/address bar.
<div class='callout'>
<img src='img/blog/posts/post-12-favico-browser-comparo.png' alt='Favicon browser comparison'>
<span class='citation'>Favicons as they are shown in Firefox 14, Chrome 21, and Internet Explorer 9</span>
</div>
<p>In 1999, Microsoft introduced Favicons for the purpose of having an icon to display in the Favorites (bookmarks) menu on Internet Explorer. 2 things were done that (nowadays) goes against some web principles:
<ol>
<li>Use of the Windows .ico file format
<ul><li>example: favicon.ico instead of favicon.jpg</li></ul>
</li>
<li>Default convention for the file location off the root of the site's domain URL, which meant the location didn't have to be specified in HTML
<ul>
<li>www.aaronkmurray.com/favicon.ico</li>
<li>This limits the webmaster's ability to place the file anywhere, or even on a different server, without mapping OS folders or making URL-rewrite rules (we'll cover those later)</li>
</ul>
</li>
</ol>
<p>As a result, even though you can now specify any location and filetype that you want for your favicon, I still recommend serving an actual favicon.ico from your root for 2 reasons:
<ol>
<li>Many browsers and RSS readers will still make requests to this location looking for an icon</li>
<li>You'll cut down on the 404 (File Not Found) error noise that will show up in your hit logging</li>
</ol>
<p>Adding a modern Favicon is simple: <code><link rel='icon' href='/favicon.png' type='image/png' /></code>
<p>But you should still slap a <a href='/favicon.ico' target="_blank">favicon.ico</a> in your root.
<p>If you don't know how to make a <a href='http://en.wikipedia.org/wiki/ICO_(file_format)' target="_blank">.ico file</a>, you can use a free site like <a href='http://www.convertico.com/' target="_blank">convertico.com</a> to upload an image and get an .ico file back.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>favicon</span>, <span class='post-tag'>icon</span></span>
<span class='post-timestamp'>Posted on September 14, 2012 @ 4:51PM</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-12.png' target="_blank"><img src='img/blog/screenshots/post-12-thumb-100.png' alt='Screenshot of site after post #12'></a></span>
</div>
<div class='blog-post-guid'>2ee06cd8-f5d6-46b4-ba6f-62aeb1c2ecf9</div>
</article>
<article class='blog-post' id='blog-post-11'>
<div class='blog-post-header'>
<span>Post 11: RSS Fix to Stop Spamming Readers</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/e91b6cf36a5f32d45ffe545a0a1b38ab8d7517f3' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Bugs! Already there are bugs :)
<p>A colleague of mine mentioned to me that whenever I release a new post, his reader fills shows that <em>all</em> of the posts appear as new posts.
<p><img src='img/blog/posts/post-11-google-reader.png' alt='Google Reader showing multiple new posts with each post'>
<p>This is an interesting problem caused by the fact that I wasn't defining a <code><guid></code> element in the RSS feed, nor a corresponding <code><id></code> element in the atom feed. These elements are what feed readers (like Google Reader) use to determine if a post/entry is new or not. If the entry doesn't have an ID, it'll always be treated as new. Obviously I need to add these Ids.
<p>So, how should I choose a unique Id for each post? Some say that a <a href='http://www.taguri.org/' target="_blank">TAG Uri</a> should be used. While that seems like a nice way to ensure the creation of a unique id, I don't really want to put a lot of effort into building these Ids by hand (since we're still not using a DB yet). Additionally, I don't care what the Ids are because they are only going to be used by machines, so they don't need to be fancy.
<p>I think this solution calls for a <a href='http://en.wikipedia.org/wiki/Globally_unique_identifier' target="_blank">Guid</a>. In fact, RSS feeds explicitly have an element for it. Bingo.
<p>The next step was realizing that I didn't want to have another manual step in the process of releaing a new post. I don't want to <a href='http://www.guidgenerator.com/online-guid-generator.aspx' target="_blank">generate</a> <a href='http://msdn.microsoft.com/en-us/library/system.guid.newguid.aspx' target="_blank">a</a> <a href='http://docs.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html#randomUUID()' target="_blank">guid</a> by hand each time. I also didn't want to store a list of guids that are mapped to blog posts in some external file.
<p>My solution for now while we're still in hand-coding mode is to add a step to rssgen that will search for a guid in each post, and if it doesn't find one, it adds it.
<p>That means that as a write a post, in the post html I have this empty stub:
<ul><li><code><div class='blog-post-guid'></code></li></ul>
<p>I <a href='https://github.com/akmurray/aaronkmurray-blog-tools/commit/70f220e27e750a3f7b339b7bcb7310e0e63620d6' target="_blank">updated rssgen</a> to add the guids inside those stubs, and then re-save the index.html file during the build process. And if I ever want to resend an update out for an old post, I can simply update the guid.
<p>This project is pretty interesting for me so far. These solutions are not the way I normally operate because I typically stand on the shoulders of giants and leverage frameworks that handle many of the details like this. My hope is that the readers learn a few things along the way, though I have a feeling that this project just may radically challenge many of my standard processes and assumptions about web development.
<p><strong>UPDATE</strong> September 14, 2012:
<p>Ironically, I had to add more changes to keep from spamming the feed readers. The changes included keeping the date timestamps from changing which would trigger a refetch/display as well.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>rss</span>, <span class='post-tag'>rssgen</span>, <span class='post-tag'>guid</span></span>
<span class='post-timestamp'>Posted on September 11, 2012 @ 12:05pm</span>
<span class='post-timestamp-updated'>Last Updated on September 14, 2012 @ 5:15pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-11.png' target="_blank"><img src='img/blog/screenshots/post-11-thumb-100.png' alt='Screenshot of site after post #11'></a></span>
</div>
<div class='blog-post-guid'>e8a8715f-24dd-44c4-9655-0aac79284aa1</div>
</article>
<article class='blog-post' id='blog-post-10'>
<div class='blog-post-header'>
<span>Post 10: The SEO Plan</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/18d9668f9164739eb7bd40ec7d305dd82fcdb66b' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>As outlined in <a href='#blog-post-1'>The Plan</a>, a major goal for this site is to provide an inside view on creating a website from the ground up. Large parts of that inside-out view is a visual history as well as full source code with revision history. While that captures the technical aspects of the site, there are other components that go into making a site.
<p>I hinted at this in <a href='#blog-post-4'>Post 4: For the Machines</a>. Another major component for creating a site is the plan to go from simply being "out there on the Internet" to being easy to find from any major search engine. Much of the steps that need to be taken are lumped into the phrase <a href='http://en.wikipedia.org/wiki/Search_engine_optimization' target="_blank">Search Engine Optimization</a>, or SEO for short.
<p>This is probably the most overlooked part of developing a site. Next week I'm going to start a 4-part series on SEO, in collaboration with guest author <a href='http://ppcwithoutpity.com/' target="_blank">Shawn Livengood who runs the blog ppcwithoutpity.com</a>.
<p>The prep for that series, it is prudent to start tracking some key SEO metrics as soon as possible. That way we'll be able to see how the changes affect those metrics over time.
<p>I won't go into too much detail know about each of these metrics, but here they are captured for historical purposes:
<ul>
<li>From Google:
<ul>
<li><a href='http://en.wikipedia.org/wiki/PageRank' target="_blank">PageRank</a>: 0/10</li>
</ul>
</li>
<li>From <a href='http://www.seomoz.org/' target="_blank">seoMoz</a> and <a href='http://www.opensiteexplorer.org' target="_blank">opensiteexplorer.org</a>:
<ul>
<li><a href='http://www.seomoz.org/learn-seo/domain-authority' target="_blank">Domain Authority</a>: <a href='http://www.opensiteexplorer.org/links?site=www.aaronkmurray.com' target="_blank">10/100</a></li>
<li><a href='http://www.seomoz.org/learn-seo/mozrank' target="_blank">MozRank</a>: <a href='http://moonsy.com/mozrank/' target="_blank">2.97</a></li>
<li>Linking Root Domains: <a href='http://www.opensiteexplorer.org/domains?site=www.aaronkmurray.com' target="_blank">2</a></li>
<li>Total Links (inbound): <a href='http://www.opensiteexplorer.org/links?site=www.aaronkmurray.com' target="_blank">5</a></li>
</ul>
</li>
</ul>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>SEO</span>, <span class='post-tag'>PageRank</span>, <span class='post-tag'>MozRank</span></span>
<span class='post-timestamp'>Posted on September 11, 2012 @ 9:25am</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-10.png' target="_blank"><img src='img/blog/screenshots/post-10-thumb-100.png' alt='Screenshot of site after post #10'></a></span>
</div>
<div class='blog-post-guid'>9b04f8d9-f240-4ce7-9eea-44c76137e097</div>
</article>
<article class='blog-post' id='blog-post-9'>
<div class='blog-post-header'>
<span>Post 9: IIS Static File Compression in web.config</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/70c9344d99d8d1025a7597cd8edba384d28a48c7' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Quick post here, while we're on the topic of saving a few bytes. I'm making 2 changes that will save some bandwidth:
<ol>
<li>Removing the useless Response Header "X-Powered-By" that gets added by IIS</li>
<li>Configure text (html, css) and javascript (js, json) files to be gzip'd automatically when the browser can handle it (ex: Accept-Encoding:gzip)</li>
</ol>
<div class='callout'>
<img src='img/blog/posts/post-9-request-sniff-1.png' alt='Request details before web.config changes'>
<span class='citation'>Request details before web.config changes (inspected using Chrome Developer Tools)</span>
</div>
<p>First of all - the Response Header "X-Powered-By" is a waste of 20 incompressible bytes (because they are in the header and the older HTTP protocol <a href='http://stackoverflow.com/questions/5333367/http-header-compression' target="_blank">does not support header compression</a> like the <a href='http://en.wikipedia.org/wiki/SPDY' target="_blank">SPDY protocol</a> does). From now on, every response sent from webserver will be 20 bytes lighter. Sweet!
<p>Secondly, we want to make sure that text files get compressed before they are sent to the client. Typically you can expect gzip'd files to be fully 2/3rds smaller than their uncompressed bretheren. In the case of this home page (index.html), the payload went from a hearty 39.67KB to a relatively svelte 12.83KB - a 67.7% savings!
<div class='callout'>
<img src='img/blog/posts/post-9-request-sniff-2.png' alt='Request details after web.config changes'>
<span class='citation'>Request details after web.config changes: gzip'd index.html payload is 67.7% smaller</span>
</div>
<p>Put this code in your web.config file and enjoy.
<p><script src='https://gist.github.com/3694724.js?file=web.config-aaronkmurray.com'></script>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>web.config</span>, <span class='post-tag'>IIS</span>, <span class='post-tag'>compression</span>, <span class='post-tag'>headers</span></span>
<span class='post-timestamp'>Posted on September 10, 2012 @ 6:30pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-9.png' target="_blank"><img src='img/blog/screenshots/post-9-thumb-100.png' alt='Screenshot of site after post #9'></a></span>
</div>
<div class='blog-post-guid'>5f6842bd-df6f-402d-b451-a7447d247db5</div>
</article>
<article class='blog-post' id='blog-post-8'>
<div class='blog-post-header'>
<span>Post 8: Automatic Image Compression</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/cc4a47493fa67f731f53abb9048cc1701cb979eb' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Alrighty, let's talk about bandwidth for a moment. Two and a half weeks ago, this site was started as a single HTML page and no external file includes aside from a screenshot. The purpose of the screenshot was to capture a visual change history of the blog so that readers could easily see how the site changed with each post without having to get the <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">code from github</a> at a certain point in time and view the site locally.
<p>These images are saved as <a href='http://en.wikipedia.org/wiki/Portable_Network_Graphics' target="_blank">PNG</a> files, which is a lossless image format meaning that all of the original image data is still intact. Unlike <a href='http://en.wikipedia.org/wiki/JPEG' target="_blank">JPEG</a> files, PNG files won't mess with the fine details of your image in order to make the file size smaller. This is both good and bad.
<div class='callout'>
<img src='img/blog/posts/post-8-png-vs-jpg.png' alt='PNG vs JPEG visual comparison. Source: jonmiles.co.uk'>
<span class='citation'>Image comparing PNG (left) vs JPEG (right) detail</span>
</div>
<p>The upside is that the screenshots look just like my screen did when I took them. The downside is that the files are bigger than a comparative jpeg file.
<p>So there are two main actions that should be taken here:
<ol>
<li>Reduce the filesize via compression utilities</li>
<li>Create separate thumbnail images and reference those for the previews</li>
</ol>
<p>For this post, I decided to tackle the compression issue first, even though creating thumbnails would have a bigger effect, simply because the utility that I wrote is more useful universally.
<p>The utility I just created, called <a href='https://github.com/akmurray/aaronkmurray-blog-tools/imgsqz' target="_blank">imgsqz</a> (image squeeze for lack of creativity), has the following purpose:
<ul>
<li>Be executed as part of the "Build" process for this site</li>
<li>Batch process entire folders full of images to compress them</li>
<li>Not waste time try to recompress images that have already been compressed (because compression can take a long time)</li>
</ul>
<p>I've checked in the tool so that you can look through the source code, but effectively just digs through a folder (and subfolders) looking for PNG files, and then trying to compress them. It keeps track of the files that it has compressed so that subsequent runs are only working on new/changed files. Using it is fairly simple:
<p><code>imgsqz.exe -s=c:\FolderWithImages</code>
<p>It's now part of the <a href='https://github.com/akmurray/aaronkmurray-blog-tools/blob/master/build/build-aaronkmurray-site.bat' target="_blank">build script for this site</a>, so that all PNG images from now on will be optimized before they hit the Internet for consumption.
<p>Here are the results for some of the files on this site:
<table id='table-png-compression-results'>
<tr><th>File</th><th>Original Size</th><th>New Size</th><th>% Saved</th></tr>
<tr><td><a href='img/blog/screenshots/post-1.png' target="_blank">img/blog/screenshots/post-1.png</a></td><td>103 KB</td><td>86 KB</td><td>16.4%</td></tr>
<tr><td><a href='img/blog/screenshots/post-2.png' target="_blank">img/blog/screenshots/post-2.png</a></td><td>90 KB</td><td>74 KB</td><td>17.7%</td></tr>
<tr><td><a href='img/blog/screenshots/post-3.png' target="_blank">img/blog/screenshots/post-3.png</a></td><td>97 KB</td><td>68 KB</td><td>30.2%</td></tr>
<tr><td><a href='img/blog/screenshots/post-4.png' target="_blank">img/blog/screenshots/post-4.png</a></td><td>88 KB</td><td>49 KB</td><td>44.8%</td></tr>
<tr><td><a href='img/blog/screenshots/post-5.png' target="_blank">img/blog/screenshots/post-5.png</a></td><td>122 KB</td><td>104 KB</td><td>13.3%</td></tr>
<tr><td><a href='img/blog/icons/icon-rss-32.png' target="_blank">img/blog/icons/icon-rss-32.png</a></td><td>1,659 bytes</td><td>1,571 bytes</td><td>5.3%</td></tr>
<tr><td><a href='img/blog/logo/logo-1.png' target="_blank">img/blog/logo/logo-1.png</a></td><td>5,025 bytes</td><td>3,181 bytes</td><td>36.7%</td></tr>
</table>
<p>Each KB of savings is worth a tiny bit of load time and a tiny bit of bandwidth. Over time these savings will add up nicely.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>images</span>, <span class='post-tag'>compression</span>, <span class='post-tag'>bandwidth</span>, <span class='post-tag'>build</span>, <span class='post-tag'>tools</span>, <span class='post-tag'>imgsqz</span></span>
<span class='post-timestamp'>Posted on September 10, 2012 @ 5:05pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-8.png' target="_blank"><img src='img/blog/screenshots/post-8-thumb-100.png' alt='Screenshot of site after post #8'></a></span>
</div>
<div class='blog-post-guid'>9d61cdb5-c803-43cf-a5d8-644839b870a9</div>
</article>
<article class='blog-post' id='blog-post-7'>
<div class='blog-post-header'>
<span>Post 7: Links to GitHub</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/b734038a5587fcbae1e8d3e317d7c06c48e18cd7' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Quick post here - I just added links to <a href='https://github.com/akmurray/aaronkmurray-blog/commits/master' target="_blank">each Post's main commit on github</a> in the post header. Just click on the <a href='https://github.com/akmurray/aaronkmurray-blog/commit/b734038a5587fcbae1e8d3e317d7c06c48e18cd7' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a> icon to see what was changed.
<p>The purpose is to make it easy to see what changed with each post, but it causes an interesting flow change for "releasing" a post because I need to make a post, and then commit the change, but then edit the post to add the new link to the change on GitHub.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>github</span>, <span class='post-tag'>commit</span></span>
<span class='post-timestamp'>Posted on September 8, 2012 @ 2:00pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-7.png' target="_blank"><img src='img/blog/screenshots/post-7-thumb-100.png' alt='Screenshot of site after post #7'></a></span>
</div>
<div class='blog-post-guid'>6825317b-ba31-4a4c-acba-67d52dfc44ca</div>
</article>
<article class='blog-post' id='blog-post-6'>
<div class='blog-post-header'>
<span>Post 6: Traffic Analytics</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/f61bdfc72b758ae365f73d4c108f44628fcbd34a' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Now that we've got a way for visitors to subscribe to the site to get notified when new posts happen, let's start capturing traffic stats using <a href='https://www.quantcast.com/aaronkmurray.com' target="_blank">Quantcast</a>.
<p>After you sign up for a free/basic Quantcast account, you can "start quantifying" your traffic by entering your domain name and generating a snippet of html/js that will ping their servers each time someone loads up your page. Simply slap that down at the bottom of your page for now, and we can start getting a rough idea of traffic stats.
<p>That snippet is polite because it does 2 things:
<ul>
<li>Try to load the tracking script using the <a href='http://davidwalsh.name/html5-async' target="_blank">async attribute</a>, which <a href='http://www.stevesouders.com/blog/2012/01/13/javascript-performance/' target="_blank">speeds</a> up the responsiveness of the site</li>
<li>Fallback to <a href='http://www.ehow.com/how_5277834_use-pixel-tracking.html' target="_blank">pixel tracking image</a> when javascript is unavailable</li>
</ul>
<p>Simple, effective, and good enough for now.
<p>Note: it will take a few days before the stats for this site show up on Quantcast.
<p><script src='https://gist.github.com/3678669.js?file=quantcast-aaronkmurray.com'></script>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>quantcast</span>, <span class='post-tag'>tracking</span>, <span class='post-tag'>traffic</span>, <span class='post-tag'>async</span></span>
<span class='post-timestamp'>Posted on September 7, 2012 @ 5:00pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-6.png' target="_blank"><img src='img/blog/screenshots/post-6-thumb-100.png' alt='Screenshot of site after post #6'></a></span>
</div>
<div class='blog-post-guid'>1497a7a5-638d-4fb2-b51c-94d67f6cc9f2</div>
</article>
<article class='blog-post' id='blog-post-5'>
<div class='blog-post-header'>
<span>Post 5: RSS, Atom, and Build Tools</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/5eb387dd03581340da8bfd120200f0666123c6d2' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Alrighty - creating a new blog these days pratically assumes that readers will be provided with an <a href='http://en.wikipedia.org/wiki/RSS' target="_blank">RSS</a> or <a href='http://en.wikipedia.org/wiki/Atom_(standard)' target="_blank">Atom</a> feed so that readers can 'subscribe' and get notified when new posts are made. I don't even follow blogs that lack such a basic service feature.
<p>Ironically, in the interest of starting from absolute square 1, this blog lacked an <a href='http://aaronkmurray.com/feeds/feed-rss.xml' target="_blank">RSS feed</a>. That was one of the more challenging pieces that I had to get over mentally when considering doing a blog this way. Fortunately, the thought of losing potential followers was ultimately outweighed by the principle of the project.
<p>That said, getting an RSS feed up ASAP was <em>very important</em> to me...even more important than other basics like choosing a database. This leads to an interesting chicken/egg problem however. How will I provide an RSS feed without a database? Am I going to copy/paste even more HTML into an XML file for a RSS feed? What about the Atom feed? Should that be another set of copying/pasting/formatting? Should I just buck up, pick a db, but not mention it until later?
<p>Well, given that this site is a fairly unique project, I'm open to fairly unique solutions as we trod down this path. So what is the solution to the feed problem? Parsing.
<p>Considering my disdain for copying and pasting, and the lack of a database to draw from, I wrote a <a href='https://github.com/akmurray/aaronkmurray-blog-tools/tree/master/rss/rssgen/rssgen' target="_blank">little parser</a> that would read the HTML from this site and produce <a href='http://aaronkmurray.com/feeds/feed-rss.xml' target="_blank">RSS</a> and <a href='http://aaronkmurray.com/feeds/feed-atom.xml' target="_blank">Atom</a> feeds automatically.
<p>Running that tool now becomes the first step in the "build" process for this site. That means that the current process for making and releasing a change to this site is now:
<ul>
<li>Edit this index.html file</li>
<li>Run my new <a href='https://github.com/akmurray/aaronkmurray-blog-tools/blob/master/build/build-aaronkmurray-site.bat'>build script</a></li>
<li>Commit and Push the changes to <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">github</a></li>
<li>Remote into the webserver hosting this site</li>
<li>Run my new <a href='https://github.com/akmurray/aaronkmurray-blog-tools/blob/master/release/release-aaronkmurray-site.bat'>release script</a></li>
</ul>
<p>While still far from ideal, this is better than <a href='#blog-post-1'>the original</a> process, and it highlights the important phases in the make/build/release process. In upcoming posts, we'll rely more heavily on these automation points and add many steps to them that handle many of the problems that still need to be solved.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>rss</span>, <span class='post-tag'>atom</span>, <span class='post-tag'>build</span>, <span class='post-tag'>tools</span>, <span class='post-tag'>command line</span>, <span class='post-tag'>build</span>, <span class='post-tag'>release</span></span>
<span class='post-timestamp'>Posted on September 7, 2012 @ 4:40pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-5.png' target="_blank"><img src='img/blog/screenshots/post-5-thumb-100.png' alt='Screenshot of site after post #5'></a></span>
</div>
<div class='blog-post-guid'>b4932981-4707-45e9-baff-adb57e36e1d6</div>
</article>
<article class='blog-post' id='blog-post-4'>
<div class='blog-post-header'>
<span>Post 4: For the Machines</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/978f856970e0d2bd911583a61db4883f24e63cb1' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>The purpose of this post is to assist the machines that will be "reading" the site.
<p>There are a couple of simple things that we need to do:
<ul>
<li>Create a <a href='http://www.robotstxt.org/robotstxt.html' target="_blank">robots.txt</a> file for communicating instructions with web crawlers</li>
<li>Add <code><meta></code> tags to help browsers and search engines</li>
</ul>
<p>You'll notice that this site's <a href='robots.txt' target="_blank">robots.txt file</a> is fairly empty. One interesting note is the line <code>Disallow: /BadBotHoneyPot/</code>
<p>I'll go over that in the future, but for now, I'll just say that we'll use that as a trap to identify "bad" crawlers so that we can automatically block them should we choose.
<p>As for the <code><meta></code> tags:
<ul>
<li><code><meta charset='utf-8'></code>
<ul>
<li>This meta tag needs to be near the top of the HTML file (before any text).</li>
<li>If it is not, or it is missing, then the browser will just try to figure out the character encoding set on it's own.</li>
<li>You will typically only run across the need to include this once you start dealing with localization of your site.</li>
<li>More info <a href='http://code.google.com/p/doctype-mirror/wiki/MetaCharsetAttribute' target="_blank">here</a></li>
</ul>
</li>
<li><code><meta http-equiv='X-UA-Compatible' content='IE=edge,chrome=1'></code>
<ul>
<li>This tag basically does two things.</li>
<li>#1: Tell Internet Explorer to use it's <a href='http://msdn.microsoft.com/en-us/library/cc288325(v=vs.85).aspx' target="_blank">most modern mode available</a> (as opposed to IE trying to determine which mode it should run in for best compatibility)</li>
<li>#2: Tells browsers with <a href='http://www.chromium.org/developers/how-tos/chrome-frame-getting-started' target="_blank">Google Chrome Frame</a> installed to render using GCF instead of their native renderer (Uncommon, mostly to help old slow browsers)</li>
</ul>
</li>
<li><code><meta name='author' content='Aaron Murray, akmurray@gmail.com'></code>
<ul>
<li>Tell the crawler who authored this page</li>
<li>Tell any users who view your source how to contact you if needed</li>
<li>This is more uncommon for sites that have multiple contributors</li>
</ul>
</li>
<li><code><meta name='description' content='...'></code>
<ul>
<li>This is a spot where you can describe your site</li>
<li>Some search engines will use this text as preview content</li>
<li>Adds some <a href='http://en.wikipedia.org/wiki/Search_engine_optimization' target="_blank">SEO</a> value to your site</li>
</ul>
</li>
<li><code><meta name='viewport' content='width=device-width'></code>
<ul>
<li><a href='https://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/UsingtheViewport/UsingtheViewport.html' target="_blank">This tag</a> is largely useful once you start wanting to have your site look nice on <a href='http://www.nokia.com/gb-en/products/phone/700/' target="_blank">small handheld</a> or <a href='http://arstechnica.com/gadgets/2011/11/microsofts-table-sized-tablet-surfaces-in-pre-order/' target="_blank">giant surface devices</a></li>
<li>We'll dive deeper into this in the future, but we've got too many bigger fish to fry at the moment</li>
</ul>
</li>
</ul>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>robots</span>, <span class='post-tag'>meta</span>, <span class='post-tag'>crawlers</span>, <span class='post-tag'>seo</span></span>
<span class='post-timestamp'>Posted on August 23, 2012 @ 11:15am</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-4.png' target="_blank"><img src='img/blog/screenshots/post-4-thumb-100.png' alt='Screenshot of site after post #4'></a></span>
</div>
<div class='blog-post-guid'>3c8edac9-4a60-4ab0-b335-e68b55329fee</div>
</article>
<article class='blog-post' id='blog-post-3'>
<div class='blog-post-header'>
<span>Post 3: Basic Visual Cleanup</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/480dc9d7c9073ec3e91b12c26b6c157cc11143d6' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Alrighty, so we have a plan, we've got the code up on <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">github</a> for the world to see, and we have made a couple small changes to make publishing *slightly* less painful via some scripts to automate a couple of steps.
<p>Despite my guts screaming out for functionality, something has to be done about the visuals around here. The look is way too 1994, and not in a cool 1994 sort of way.
<p>I'm going to start attaching a screenshot of the site with each post so that in the future we can easily view the visual progress that is being made. This will be easier than checking out snapshot from the <a href='https://github.com/akmurray/aaronkmurray-blog/commits/master/' target="_blank">github commit history</a> and running the site locally. In the future this will be harder for folks to do once we get distributed and have various databases powering the content. Fun stuff!
<p>Back to reality - let's spruce this place up. For all of the newbs out there, the best way to fancy up the visuals on a web page is to sprinkle a little <a href='http://www.w3schools.com/css/' target="_blank">CSS</a> love around. Quickly you'll learn about one of the most loved (hated) aspects of web development: browser differences. Luckily there are <a href='http://www.alistapart.com/' target="_blank">resources</a> out there to help. For now we won't get into the weeds, but let's just say that for nearly 2 decades we've been struggling with browser differences and there is no end in sight, but at least there is a lot of <a href='http://html5.org/' target="_blank">hope</a> that things will get better over the next decade as <a href='http://www.ie6countdown.com/' target="_blank">older browsers start to die off</a>.
<p>Step 1: very basic <a href='http://en.wikipedia.org/wiki/User_interface' target="_blank">UI</a>/<a href='http://en.wikipedia.org/wiki/User_experience_design' target="_blank">UX</a> stuff:
<ul>
<li>Visually split up the site header from the posts</li>
<li>Split up the post from each other</li>
<li>Format certain types of text (<span>like code</span>)</li>
<li>Enable a way to link directly to a specific post</li>
<li>Add some content to the footer area of the page</li>
</ul>
<p>Let's assume that we'll use <code><div></code> tags for HTML structure/grouping, and that text should be in either a <code><span></code> or a <code><p></code> tag.
<p>Using css, we can add some a style for blog posts that have a <code><span></code> tag with a css class of <code><code></code>. These matching tags will be in a different monospace font to make look them more computery. Easy.
<ul>
<li><code><style> .blog-post-body span.code {font-family: monospace, Courier, Lucidatypewriter; } </style></code></li>
</ul>
<p>To enabling linking directly to a post, we're going to use the old-school method of using <code>name</code> attributes and <code>#</code> links. I know this is absurd in the days of <a href='http://www.bloggingbasics101.com/2008/11/what-is-a-permalink/' target="_blank">permalinks</a> and SEO friendliness, but we haven't written the permalink code yet, so we suffer for now. I'm doing this for your own benefit here folks - it's my <a href='http://en.wikipedia.org/wiki/PageRank' target="_blank">PageRank</a> that will suffer. When we fix this later, it'll also be a great time to talk about the joys of <a href='http://en.wikipedia.org/wiki/Code_refactoring' target="_blank">refactoring</a> and <a href='http://en.wikipedia.org/wiki/Brownfield_(software_development)' target="_blank">brown-field</a> upgrades.
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>css</span>, <span class='post-tag'>html</span></span>
<span class='post-timestamp'>Posted on August 22, 2012 @ 6:10pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-3.png' target="_blank"><img src='img/blog/screenshots/post-3-thumb-100.png' alt='Screenshot of site after post #3'></a></span>
</div>
<div class='blog-post-guid'>95f8c883-3c79-4f4c-87e0-71fd7c631a62</div>
</article>
<article class='blog-post' id='blog-post-2'>
<div class='blog-post-header'>
<span>Post 2: Deploying New Posts</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/7d1cbce99a47e5b5e37f46c98293d5ab5821715d' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>Already there is pain. Currently, my brand new process when I want to write a new post is:
<ul>
<li>Open up my <a href='http://www.editplus.com/' target="_blank">text editor</a> of choice</li>
<li>Copy and paste the HTML for a post from my previous post</li>
<li>Edit the old HTML</li>
<li>Save and preview the file (testing testing testing)</li>
<li>Fix my bugs (remember to edit the timestamp, post tags, etc)</li>
<li>Commit the changes to <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">github</a> using <a href='http://code.google.com/p/tortoisegit/' target="_blank">TortoiseGit</a></li>
<li>Push the changes to <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">github</a> using <a href='http://code.google.com/p/tortoisegit/' target="_blank">TortoiseGit</a> (Manually enter username and password each time in the prompt boxes)</li>
<li>Remote into the webserver hosting this site</li>
<li>Pull the changes from github to a local folder</li>
<li>Copy the files to the IIS folder hosting the site</li>
</ul>
<p>Ugh. No fun already. I know we can do better than that. First up, let's automate a couple of those steps.
<ul>
<li>Install <a href='http://msysgit.github.com/' target="_blank">Git for Windows</a> (<a href='http://www.thegeekstuff.com/2012/02/git-for-windows/' target="_blank">how-to</a>)</li>
<li>Select the option for "Run Git from the Windows Command Prompt" so that we can write scripts to do our work</li>
<li>Make sure that worked (open a Command Prompt, type in "git" and hit Enter</li>
<li>Clone the github repo to a local directory. <code>c:\code\git>git clone https://github.com/akmurray/aaronkmurray-blog c:\code\git\aaronkmurray-blog</code></li>
<li>Make a new Windows .bat file that will download latest code and copy to local website folder:
<ul>
<li><code>cd c:\code\git\aaronkmurray-blog</code></li>
<li><code>git pull https://github.com/akmurray/aaronkmurray-blog</code></li>
<li><code>xcopy /Y /E /R /V /I "c:\code\git\aaronkmurray-blog" "C:\inetpub\wwwroot\aaronkmurray"</code></li>
<li><code>REM pause</code></li>
</ul>
</li>
</ul>
<p>Now we can just run that file on the webserver and it'll fetch the latest source from github and push it to the website's folder.
<p>Next up, let's take out the step of entering a username/password each time when doing the <code>git push</code>. <a href='http://www.programmoria.com/2012/02/saving-tortoisegit-password.html' target="_blank">Here is an article</a> that describes the simple step of creating a batch file, and then running it, enter your username and password, and it creates the file that TortoiseGit needs so that you don't have to enter those manually anymore.
<p>Far from perfect, but we're taking baby steps here ;)
<p>Article on <a href='http://longair.net/blog/2009/04/16/git-fetch-and-merge/' target="_blank">git fetch vs pull</a>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>git</span>, <span class='post-tag'>command-line</span></span>
<span class='post-timestamp'>Posted on August 22, 2012 @ 4:00pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-2.png' target="_blank"><img src='img/blog/screenshots/post-2-thumb-100.png' alt='Screenshot of site after post #2'></a></span>
</div>
<div class='blog-post-guid'>1a761ec2-aecf-43c2-a76f-4eebdabf6b51</div>
</article>
<article class='blog-post' id='blog-post-1'>
<div class='blog-post-header'>
<span>Post 1: The Plan</span>
<span class='commit-link'><a href='https://github.com/akmurray/aaronkmurray-blog/commit/be3aa221316ebdab153ab31f43d9c03b9df65fc3' target="_blank"><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github'></a></span>
</div>
<div class='blog-post-body'>
<p>This has been a long time coming.
<p>I've been wanting to start blogging for about a year now, but have been struggling with figuring out where to start.
<p>There have been tons of questions swirling around in my head, like:
<ul>
<li>Blog: Roll my <a href='http://www.tandemgames.com/' target="_blank">own</a> <a href='http://www.domainofheroes.com/' target="_blank">site</a> <a href='http://www.aliensandrobots.com/' target="_blank">again</a>? or use seasoned blog <a href='http://dasblog.codeplex.com/' target="_blank">software</a> with <a href='http://wordpress.org/' target="_blank">heavy community support</a>?</li>
<li>Host: Use a <a href='https://appharbor.com' target="_blank">cloud</a> <a href='http://www.heroku.com/' target="_blank">application</a> <a href='http://www.rackspace.com/cloud/public/sites/' target="_blank">host</a>? Use a cheap host that <a href='http://bluehost.com/' target="_blank">supports simple scripts</a> for common apps? Host out of the <a href='img/blog/posts/post-1-aarons_server_rack.jpg' target="_blank">server rack in my house</a>?</li>
<li>Platform: Java? .NET? "pure" HTML/JS? <a href='http://expect.sourceforge.net/cgi.tcl/'>TCL/CGI</a>? Something more <a href='http://rubyonrails.org/' target="_blank">hip</a>?</li>
<li>Audience: Should I be connecting with <a href='http://lostechies.com/' target="_blank">other developers</a>? Other small-business owners? Friends? Family? </li>
<li>Content: Is this going to be a personal activity log? Professional journal? Or just another tech experiement?</li>
</ul>
<p>As I poured through ideas and wrote down reams of notes, one thing was apparent: <span class='callout'>I was spending a lot of time and effort on the blog but not actually blogging.</span>
<p>Last night I couldn't sleep. The kid's toy keyboard was "cleaned up" in a way that a key was being pressed repeatedly whenever the air conditioning changed the pressure in the play room. I finally got up to address the situation, and then found myself unable to fall back to sleep.
<p>After laying in bed for a couple of hours thinking about the blog, I finally got up to write down my ideas on paper so that I could actually fall asleep. This is common for me: the fear of forgetting an idea keeping me from drifting off into sleepytown.
<p>This morning I get into work and checked on my RSS feed folder for .NET development. It's been a few days since I checked it, but <a href='http://www.hanselman.com/blog/YourWordsAreWasted.aspx' target="_blank">this call-to-action from Scott Hanselman</a> was the final straw. The answer is simply to start blogging now and sort out the details later.
<p>So what's the plan? Well, the plan is:
<ul>
<li>Roll my own site/blog from the ground up</li>
<li>Hosted at my house in my server rack</li>
<li>Post about all of the changes and more importantly, show the intention behind them</li>
<li>Make this site <a href='https://github.com/akmurray/aaronkmurray-blog' target="_blank">publicly available on github</a> so that everyone can see how it works and see it progress</li>
<li>Start with a single index.html file and advance the site it all the way through to a scalable, distributed system, from the ground up</li>
</ul>
<p>Ultimately, I'd like to think that someone new to the web development craft will be able to use this site, the posts, and the source code history as a guide to seeing what goes on behind the scenes for how to create modern web software. I'm going to start at absolute step 1, and advance steadily through the growth of a real application.
<p>I'd love it if you followed me on this journey. It'd be great if you could sign up for an RSS feed to get auto-notifications when I make new posts, but since this is just an index.html file at the moment, you can't. Looks like we've got a lot of work to do. Get ready for a fun ride.
<p>For now, you can reach me on <a href='https://twitter.com/aaronkmurray' target="_blank">Twitter @aaronkmurray</a>. Let me know what you think about this project and what features you'd like to see implemented. Here's a sample of what I have planned already:
<ul>
<li>Basics: CSS reset, JS framework, Cloud/CDN hosting</li>
<li>Javascript: organizing your JS files (custom and 3rd-party), creating your own framework patterns, debugging</li>
<li>CSS: responsive design, image bundling/sprites</li>
<li>Build/Deploy: tools for building, bundling, and deploying the site and assets</li>
<li>Performance: optimizing response time, payload, client-side caching, server-side caching, web-server and load balancer config</li>
<li>Debugging: client-side debugging, server-side debugging, error logging, pro-active notifications, self-healing services, system health dashboards and reports</li>
<li>Testing: js unit testing, server-side testing, integration testing</li>
<li>Database: choosing a DB, using an ORM (like Entity Framework), writing your own ORM</li>
<li>Marketing: strategy, considerations, tracking and mining your own site data</li>
<li>Social: integration with the Majors (Facebook, Twitter, Instagram, Pinterest, etc.), API usage, tracking</li>
<li>Advanced: client-side MVC, new JS paradigms and protocols for server communication, custom DBMS!</li>
</ul>
<p>As you can see, that is a reasonably ambitious sampling of goals since we're starting with a single HTML page and no code. Let's get cracking!
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'>site-story</span>, <span class='post-tag'>insomnia</span>, <span class='post-tag'>plan</span>, <span class='post-tag'>twitter</span>, <span class='post-tag'>git</span></span>
<span class='post-timestamp'>Posted on August 22, 2012 @ 3:00pm</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-1.png' target="_blank"><img src='img/blog/screenshots/post-1-thumb-100.png' alt='Screenshot of site after first post'></a></span>
</div>
<div class='blog-post-guid'>a882e042-86e5-4d3e-b1c7-f970cf2e0769</div>
</article>
<!-- Someday we'll have a database for these posts and I won't need this copy/paste template :) -->
<!--
<article class='blog-post' id='blog-post-?????'>
<div class='blog-post-header'>
<span>Post ?????: </span>
<span class='commit-link'><a href='#' target=_blank><img src='img/blog/icons/icon-github-16.png' alt='View the code changes related to this post on github' /></a></span>
</div>
<div class='blog-post-body'>
<p>
<p>
<p>
</div>
<div class='blog-post-footer'>
<span class='post-tags'>Tags: <span class='post-tag'></span>, <span class='post-tag'></span>, <span class='post-tag'></span></span>
<span class='post-timestamp'>?</span>
<span class='post-screenshot'><a href='img/blog/screenshots/post-?????.png' target=_blank><img src='img/blog/screenshots/post-?????-thumb-100.png' alt='Screenshot of site after post #?????' /></a></span>
</div>
<div class='blog-post-guid'></div>
</article>
????? REMINDER for Mr. No Database: Add an entry to the Posts section of the menu on the right
-->
</div>
<div id='wrapper-sidebar'>
<div id='wrapper-logo'>
<div id='logo-cube' class='show-side-1'>
<figure class='side-2'><img src='img/blog/logo/logo-2-128.png' class='logo' alt='site logo'></figure>
<figure class='side-3'><img src='img/blog/logo/logo-3-128.png' class='logo' alt='site logo'></figure>
<figure class='side-4'><img src='img/blog/logo/logo-4-128.png' class='logo' alt='site logo'></figure>
<figure class='side-5'><img src='img/blog/logo/logo-5-128.png' class='logo' alt='site logo'></figure>
<figure class='side-6'><img src='img/blog/logo/logo-6-128.png' class='logo' alt='site logo'></figure>
<figure class='side-1'><img src='img/blog/logo/logo-1-128.png' class='logo' alt='site logo'></figure>
</div>
</div>
<div id='wrapper-blog-post-menu'>
<div class='menu-header'>Posts</div>
<ul>
<li><a href='#blog-post-1'>Post 1: The Plan</a></li>
<li><a href='#blog-post-2'>Post 2: Deploying New Posts</a></li>
<li><a href='#blog-post-3'>Post 3: Basic Visual Cleanup</a></li>
<li><a href='#blog-post-4'>Post 4: For the Machines</a></li>
<li><a href='#blog-post-5'>Post 5: RSS, Atom, and Build Tools</a></li>
<li><a href='#blog-post-6'>Post 6: Traffic Analytics</a></li>
<li><a href='#blog-post-7'>Post 7: Links to GitHub</a></li>
<li><a href='#blog-post-8'>Post 8: Automatic Image Compression</a></li>
<li><a href='#blog-post-9'>Post 9: IIS Static File Compression in web.config</a></li>
<li><a href='#blog-post-10'>Post 10: The SEO Plan</a></li>
<li><a href='#blog-post-11'>Post 11: RSS Fix to Stop Spamming Readers</a></li>
<li><a href='#blog-post-12'>Post 12: Favicon</a></li>
<li><a href='#blog-post-13'>Post 13: Image Thumbnails</a></li>
<li><a href='#blog-post-14'>Post 14: SEO Part 1/4: Getting Indexed</a></li>
<li><a href='#blog-post-15'>Post 15: CSS Includes</a></li>
<li><a href='#blog-post-16'>Post 16: HTML Markup Cleanup</a></li>
<li><a href='#blog-post-17'>Post 17: First Month Retrospective</a></li>
<li><a href='#blog-post-18'>Post 18: SEO Part 2/4: Optimizing Code Tags For SEO</a></li>
<li><a href='#blog-post-19'>Post 19: Fun With A CSS3 Cube</a></li>
</ul>
</div>
</div>
<div id='wrapper-site-footer'>
<span class='copyright'>© Copyright 2012, <a href='https://twitter.com/aaronkmurray' target="_blank">Aaron Murray</a></span>
<div id='wrapper-site-footer-icons'>
<a href='http://aaronkmurray.com/feeds/feed-rss.xml' target="_blank" title='Subscribe via RSS'><img src='img/blog/icons/icon-rss-16.png' alt='RSS icon'></a>
<a href='https://twitter.com/aaronkmurray' target="_blank" title='Follow me on Twitter @aaronkmurray'><img src='img/blog/icons/icon-twitter-16.png' alt='Twitter icon'></a>
<a href='https://github.com/akmurray' target="_blank" title='View the code for this site on GitHub'><img src='img/blog/icons/icon-github-16.png' alt='GitHub icon'></a>
<!--
my gists: https://gist.github.com/akmurray
-->
</div>
</div>
<!-- Quantcast Tag -->
<script type='text/javascript'>
var _qevents = _qevents || [];
(function() {
var elem = document.createElement('script');
elem.src = (document.location.protocol == 'https:' ? 'https://secure' : 'http://edge') + '.quantserve.com/quant.js';
elem.async = true;
elem.type = 'text/javascript';
var scpt = document.getElementsByTagName('script')[0];
scpt.parentNode.insertBefore(elem, scpt);
})();
_qevents.push({ qacct:'p-M_hV8wgLbE9k_' });