I have <span id="numApps"></span> coding samples in the form of web apps. If you are a hiring manager, code samples are available upon request.<br/>
</br>
These are not necessarily apps of general interest, but were of interest to me. They
satisfy certain requirements I had at the time.
<ul>
	<li>They met a need I had.
	</li>
	<li>They gave me an opportunity to try/use certain techniques and technologies.
	</li>
	<li>I wanted them to be serverless.
		<ul>
			<li>I've written server code before, didn't want to now.
			</li>
			<li>I didn't want to pay for a server or server instance.
			</li>
			<li>I didn't want to violate Comcast's (my ISP) Terms and Conditions by running a server at my house.
			</li>
			<li>Experimenting with free server instances offered was a failure. I
				   tried about 4 or 5 different services, none were reliable or offered what I needed.
			</li>
			<li>I did want apps that had instances sharing data. To that end I
discovered Firebase. At the time of this writing, it is a beta product, that
has has been very reliable and fun to use. In that respect, I'm really not serverless, but I
have no code of mine running at Firebase. My web apps' Javascript communicates
with Firebase through a handful of calls to their API. 
			</li>
		</ul>
	</li>
	<li>I wanted them to be as frictionless as possible. As such, they have no
registration or logins. (But you do get your own data, it is not shared with
everyone else using the app.)
	</li>
	<li>I didn't want to test on a multitude of platforms, browser versions,
etc. For the most part, they've worked on the latest (at the time of
development) versions of Firefox and Chrome on Windows 7, and my very old
iPhone 3GS running iOS 4.3.5. Your mileage may vary.
	</li>
	<li>I occasionally considered programming around or not using features
that might not exist in old versions of browsers, but wasn't meticulous about
the point. For example, I assumed I have localStorage capabilities to store a
user ID, so that I can retrieve data from Firebase at a later time.
	</li>
	<li>I did not work from a design document, or even a firm design in my
head. It was an evolving design, based on what I wanted to try next, what I
thought was a good trade-off at the moment between amount of effort needed and
the payoff I thought I would get from the effort. As such, there are numerous
things that seem obvious that could enhance the apps. Some I may do in the
future, but will probably find something else more interesting and, therefore,
not do.
	</li>
	<li>
	</li>
</ul>
<h2>My apps</h2>
<h3>I've Watched, You Can Delete</h3>
My reason for doing this app was to replace a pad of paper that I used for one
specific purpose. There are two DVRs in my home. One gets used almost
exclusively by one member of the household, the other is shared. I generally
manage the shared DVR. It often contains shows watched by both members of the
household, but almost 100% of the time I watch first those shows we both
watch, and they are later watched and deleted from the DVR by the other
viewer. As such, I'd watch a show, write the show name and broadcast date on
the pad of paper. Eventually the other member of the household would see it on
the pad, watch the show, and delete it from the DVR.
<br/>
Well, the pad of paper got old. Meaning I got tired of it, and it got
dog-eared from the cats sitting on it. (Does that mean it got cat-eared?) This
app replaces that piece of paper.
<br/>
Things about that app that might be of interest:
<ul>
	<li>I only wanted one app, not two. A case can be made for two, as the use
cases are asymetrical. But there are enough similarities between the two that
I let my desire to only change things in one place rule.
	</li>
	<li>To simplify the UI the second person had to see, they didn't need to
see the UI parts that allow show episodes to be added to the list.
Additionally, since I didn't want to clutter the UI, there's no UI to set the
names of the DVRs ("Family Room" and "Kitchen").
	</li>
	<li>Mostly because Firebase makes it SOOoo simple to do, the UI updates
when either user updates information, usually in milliseconds.
	</li>
	<li>I wanted the app to run fairly well on both the desktop within view of
the TV connected to the DVR and an iPhone of a person on the sofa watching TV.
	</li>
	<li>I wanted you, the reader of this page, to be able to try the
app out, and not have to worry about messing up my data. You get your own
data.
	</li>To satisfy the two constraints immediately above, I needed a way to
have a new user get a new data list. They needed to be able to use that data
on a second (or more) device/browser. They needed a way to share this list
with a second user. I wanted this all without running counter to my desire to not have a
login or registration. The solution to this was as follows. The first person
of the pair visits the bare URL, 
<a href="http://webapps.nfshost.com/ivewatched">webapps.nfshost.com/ivewatched</a>.
At the bottom of the app, there's a section of the app labeled "Share", which
when displayed shows two versions of the URL with query strings attached. One
link is for the first person to use on a second device. The second link is for
the second person to use. Both links will associate the users with the new
data list. Feel free to try it out, you won't mess up my data, or anyone
else's.
	<li>I created a debugging option of logging messages to Firebase. This
made it easier to debug issues on my iPhone by having the debugging output
show up in the app (both on my phone and the desktop). This was far easier
than enabling the debug console in mobile Safari on the iPhone.
	</li>
	<li>In one instance, I wanted the size of a button and the text that
replaced the button when it was pressed to be the same. (Check out what
happens when you hit the DEL button next to an episode. The DEL button is
replaced by the text "Delete". I wanted the show name to remain in place, not
jump a couple pixels right or left.)  I wanted to use the
button that were native to the platform. The text and buttons were different
sizes on Firefox, Chrome, and mobile Safari. I could have accomplished that by
oversizing everything to accomodate all three platforms, but I wanted
everything as small as possible due to the limited space available on the
mobile platform. It was more fun to dynamically measure the sizes of the
elements and their borders, margins, and padding and make the most minimal
change to accomplish the purpose.
	</li>
	<li>Again, feel free to try it out, you won't mess up anyone else's data.
<a href="http://webapps.nfshost.com/ivewatched">webapps.nfshost.com/ivewatched</a>.
	</li>
</ul>
<h3>Dimensional Analysis Calculator</h3>
<ul>
	<li>
	</li>
</ul>