Dec272010

pixelstyle: Mega Man 2, NES – 1989

pixelstyle:

Mega Man 2, NES – 1989

No comments · Written by Nathan at 10:08 am · Tags

Dec222010

A Holiday Message from Nathan Demick:
Why I’m not an Atheist

If you browse the internets with any degree of frequency, no doubt you’ve seen an essay by Ricky Gervais making the rounds. Gervais is a British actor, most famous for creating the TV show “The Office.” In this essay, entitled “A Holiday Message from Ricky Gervais: Why I’m An Atheist,” he promotes his atheistic beliefs, apparently as a counterpoint to whatever religious symbolism is still left in our culture’s Christmas celebration.

Gervais starts out by attempting to be humble. When people ask him why he doesn’t believe in God, he says, “I still give my logical answer because I feel that not being honest would be patronizing and impolite.” Unfortunately, his honest answer, as detailed in the rest of the essay, felt very patronizing to me. I’ve attempted here to form a counter-point: “A Holiday Message from Nathan Demick: Why I’m not an Atheist.”

Many people use the idea of empirical science as their reason for not believing in God. “In the ancient past,” they reason, “man had no idea how the world worked. They created this idea of a “god” to explain natural phenomena. We now know how the world works, and the supernatural has no place in it. We can’t test the existence of a deity, so therefore there is none.” Yes, it’s impossible to prove there is a God. But there are many pieces of evidence that, if we choose to consider them, point to his existence.

Consider the “lowly” cell: although it is the most basic component of biological life, it is ridiculously complex in its’ own right. Just one cell is a marvel of biological engineering… but science doesn’t have an answer for how cells originated. There are theories and conjectures, but no repeatable tests that can prove to us how life started. We can believe that life formed through naturalistic means. Or we can believe that the complexity of life was started by God. To be honest, both views seem a bit ridiculous at first glance. “Life was created by an all-powerful, invisible man.” Or, “Life formed spontaneously out of nothing.” But the first is less ridiculous, because of what I’ve learned through science.

If, while on a walk, you come across an arrangement of rocks (let’s use Stonehenge as an example), you might consider how the stones came to be in that formation. Well, even primitive structures like Stonehenge are obviously the result of someone’s will. How can we consider the intricacies of life to be the result of some ex nihilo naturalistic phenomenon? It’s like finding an iPad on the ground and saying, “Hey, that’s a pretty cool rock!” Science tells us that nature does not produce order from disorder, or life from nothing.

In Romans 1:20, Paul writes, “For since the creation of the world God’s invisible qualities—his eternal power and divine nature—have been clearly seen, being understood from what has been made, so that people are without excuse.” Nature itself (and science, which is the observation of nature) is evidence for God.

Just as we must choose between atheism and theism, a theist must choose what deity to believe in. That choice is made by examining the philosophy that a religion espouses, and deciding whether the physical evidence and our observations about life fit in with that philosophy. Studying religious texts is the easiest way to do this in many cases. In the case of Christianity, this would mean determining whether the Bible (a combination of Jewish and Christian religious writings) is a valid source of knowledge.

One way of determining its’ validity is to look at its’ contents. For example, the Bible claims to have been written by God through the inspiration of human authors. Part of their writings include predictions of the future. If these predictions were verified to be false, we could immediately determine the text to be unreliable. However, the oldest copies of Biblical texts have been dated to long before the events they predict (for example, when Jesus was supposed to appear — Google “Daniel 9″). Is this proof that God exists? No, but it’s another chunk of evidence that you should consider before making your decision.

Some people today reject “Christian morals.” They feel that such rules infringe on human rights — to live in whatever way seems best to them. “That’s the way I am; I can choose for myself,” they might say. Well, consider the psychotic serial murderer. Why can’t he live his life in the way that comes most naturally for him? “It’s not right,” you might say. But who are you to say what is right for others? Does society determine what’s right? In 1940′s-era Germany, “right” was genocide against “ethnically inferior” people. Without an absolute source of truth, the morality of our actions is completely relative.

The Bible claims that humans were created to live in a certain way. Humans were created perfect, but made the choice to decide good and bad for themselves. When our ancestors did this, they introduced evil into the world — man’s will instead of God’s will. This is evident when we consider what’s observable about people: we have capacity for greatness, but also depravity. In this case, the Bible perfectly describes the human condition, which is another piece of evidence that I consider in my choice.

These are some of the things I think about when others question my belief. I’m sure that this was a bit more rambling and disjointed than I’d hoped, but let me know in the comments if you’d like clarification. Just as I use the critiques of others as an opportunity for reflection, I hope you will too. In the end, your decision is your decision; just make sure that you’ve considered the evidence first.

1 comment · Written by Nathan at 9:43 am · Tags , ,

Dec172010

Intro to Load Testing
with JMeter (part deux!)

If you’ve been following along, you’ll know that JMeter is most commonly used to do automated testing; you can create a bunch of virtual users to perform a set of pre-determined actions on your website. In my previous post, I detailed how to manually create a list of actions for your test users to perform. However, manually creating long lists of test actions is kind of a pain! Fortunately, JMeter includes a proxy utility that can intercept your browser requests and store them as user actions.

Fire up JMeter, and you’ll be presented with a new plan. Create a new thread group (your users) in the Test Plan (as detailed in the previous tutorial). Now, instead of manually adding HTTP Requests for these users to perform, we’ll hook up a proxy server to create the HTTP Requests for us.

Right-click on the WorkBench item in the sidebar, and select Add > Non-Test Elements > HTTP Proxy Server. You don’t have to configure anything here, just click the Start button at the bottom of the config window to start the proxy server on port 8080. Now you’ll have to configure your browser to pass its’ requests through the proxy server. In Mac OS X, you do this system-wide by accessing your System Preferences. Go to System Preferences > Network > Advanced (the “Advanced” button is in the lower-right corner of the window). When the advanced options window pops up, click the Proxies tab, then check the Web Proxy (HTTP) option, and change the Web Proxy Server port to 8080. Click OK to save your changes, then Apply to make them take effect.

Next, open your browser and go to the JMeter homepage (http://jakarta.apache.org/jmeter/). Click a few links, and then go back to your JMeter window. There should now be an arrow next to your thread group, meaning that the group contains some actions. Click the arrow to expand the list, and you should see requests for all the resources that you requested in your browser. You’ll see that requests have been made for every resource your browser asked for, such as images and CSS files. You can remove those requests if you want, or leave them in for a more realistic simulation.

Don’t forget to go back into your Network settings and disable the proxy server, otherwise you won’t be able to make HTTP requests when you close JMeter. However, this method of creating JMeter test cases is way easier than its’ manual counterpart.

No comments · Written by Nathan at 8:00 am · Tags , , , ,

Dec102010

Phil: I’m taking pictures of the borq queen and her
offspring today Me: No kidding? Prepare to be as

Phil: I’m taking pictures of the borq queen and her offspring today
Me: No kidding? Prepare to be assimilated

No comments · Written by Nathan at 9:45 am · Tags

Dec072010

Intro to load testing with JMeter

Recently for a project at work, I was tasked with doing research into load testing software. Now, there are tons of options for load testing; in my search I found some nice-looking hosted solutions, such as browsermob.com. But of course, if you can get away with doing something for free, that’s usually the option that makes the most business sense (that is, if the time you invest in learning the free tool is less than the money you would save by using the easier solution). The free solution in this case is JMeter, a Java-based program maintained by the Apache Foundation. Since I gained a basic understanding of the software through my recent research, I thought I’d share a bit here on how to create a basic load testing script. JMeter has many more options that what I’ll detail here, but hopefully this tutorial will at least get you over the initial learning curve.

Obviously, first of all you should download JMeter. Unzip the downloaded package, and place the whole folder structure somewhere easy to remember. If you want, you can set the /bin directory on your path so you can start the program from the command line. I just double-click the ApacheJMeter.jar package to start the program.

After JMeter starts up, you’ll be faced with a totally blank slate. What we want to do is create a group of users, and have each of those users perform a certain sequence of actions (such as access a URL, post a form, or whatever). There are two ways to do this with JMeter: enter the sequence by hand, or configure a proxy server to intercept your browser requests and save them as an action sequence. If the list of actions you want to perform is complex, it might be a good idea to set up a proxy. I’ll show you how to manually set up your test; running the proxy server will be reserved for a future post.

First, let’s rename the test plan to be something more descriptive. Click on the “Test Plan” text in the project sidebar, and rename it to something descriptive, such as “My Jawesome Test Plan.” Now, the first step in creating your test scenario is to make a group of users. Right click on your test plan, then select Add > Threads (Users) > Thread Group. “Thread Group” is kind of a confusing term, so you can rename the group to “Users” if you want. When you click on your user group in the sidebar, you’ll see there are various options you can change about it, the most significant being the number of users, how fast they start performing their tasks, and whether they repeat their tasks. Change the number of users to 10, and the ramp-up period to 10 as well. That means that it’ll take 10 seconds for all the users to be activated. Since there are 10 total users, that means that one will start up each second. Change the loop count to 2, so that each user runs through their tasks twice.

Next, we’ll add some configuration options to the test, so that you don’t have to enter certain info each time you want to add an action for the user group to perform (such as the base site URL). Right-click your user group and select Add > Config Element > HTTP Cache Manager. This simulates a browser cache for each of your users, so if they download a static resource on the first test run, they’ll have a cached version for the second, making the test more realistic. Select the user group again, right-click, and choose Add > Config Element > HTTP Request Defaults. You can put in any default options you want here, such as the site name, port number, and path. So for example, if you were testing your site foo.com, you could put in “http://foo.com” as the server name. Then all subsequent requests from your users would use that information. If a user requested plain ol’ “bar.html,” the defaults would be prepended to that request, resulting in a request to “foo.com/bar.html.” When creating a test by hand, the Request Defaults configuration becomes very useful. For our example, let’s query the JMeter site, so in the HTTP Request Defaults options, enter “http://jakarta.apache.org” as the server name.

OK, we’ve got the test users all set up. Next, let’s have them try to make some requests. Right click on your user group in the sidebar, and select Add > Sampler > HTTP Request. This represents a request for a single page or resource on your site. Let’s have it request the JMeter homepage. If you remember, we already set up the default site URL and path, so the only option we have to change for the sampler is the path value, which we’ll set to “/jmeter/index.html” (for the homepage). Also, change the name of the HTTP Request to “JMeter Homepage” so that it’s easier to see what it’s requesting.

At this point, you’ve got enough set up to actually run the test and see real results, but let’s go ahead and add another HTTP Request to the test. Right-click your user group, add another HTTP Request, and set the path to “/jmeter/usermanual/index.html.” Rename this request to “JMeter User Manual.” Now the test is completely set up, but there’s no way to view the test results yet. To remedy this, we’ll add two “listeners,” which track results and display them in a human-readable way. Right-click your user group, and select Add > Listener > Graph Results. Also Add > Listener > Summary Report. These are two simple listeners that show your results in a graph and text-based summary.

Now, go ahead and run the test by choosing Run > Start (or Command-R). Wait for a bit for the test to finish, then click on your results listeners. You should see the (hopefully successful) results of your test. Now for some embellishments. In a more realistic scenario, users would load a page, read it for a few seconds, then click a link to go to a different page. In the test script right now, your users make requests as fast as they can. To insert a random delay between requests, right click each HTTP Request in the sidebar, and choose Add > Timer > Uniform Random Timer. This timer allows you to set a base constant delay (such as 2 seconds), and then add another random delay on top of that. I like to have a 2 second constant delay and a 3 second random delay, so go ahead and edit both timers to have values of 3000 (random) and 2000 (constant). Also, ideally we want to make sure that the results of each request were successful. There are a number of ways to do this in JMeter, but the simplest is to make an assertion that each request returned a HTTP status code of 200. Right-click each of the HTTP Requests and choose Add > Assertions > Response Assertion. Modify each assertion to check the Response Headers, choose “Equals” for the Pattern Matching Rules, and add “200″ as a Pattern to Test. The Response Assertion is very powerful… you can modify it to check for patterns in the HTML of the requested page, etc., but this basic assertion is enough for our needs right now.

And that’s it! You now have a fully functional basic test plan. You can run it and see a cool graph of response times as well as get the summary report for the whole test. Hopefully that will get you started with the wonderful world of load testing.

2 comments · Written by Nathan at 8:00 am · Tags , , , ,

← Newer Posts — Older Posts →