Awesome Princess

Nerdy Projects

Princess — Sat, 27 Dec 2008 02:00:00 GMT

I am nerd at heart and I constantly find myself getting wrapped up nerdy projects. Lately, I've been nerding out on:

StackOverflow: a side-project of two well-known bloggers, Jeff Atwood and Spolsky. Weirdly addicting website where you can ask and answer questions about programming and software development. I post as Princess.
Wikibooks: F# Programming: I'm writing a wikibook on the F# programming language. I been working on this book in my free time, and its coming along fairly well. It still has a long way to go, but F# newbies should find the first few chapter relatively accessible and easy to read.
In all of the years I've been programming, I've only ever used arrays, linked lists, and hash tables, due in part because I've only ever written trivial forms-over-data applications. I've never bothered to learn about red-black trees, splay heaps, triangular arrays, or any other uncommon datastructures. Additionally, I've never learned about implementing any datastructures in functional programming languages. I'm taking the time to read Purely Functional Datastructures and F# for Scientists to bulk up my nerdiness.

Now that's depressing

Princess — Sat, 27 Dec 2008 01:13:00 GMT

So, I've been at my new job for the 2 weeks. I was mucho happy with my first paycheck, and I'm happy with my job.

My company sells insurance software, sells warranties, processes claims, provides claims estimates, etc. However, much of the processing is manual: whenever clients want to buy a warranty, they call one of our data centers to have a form faxed over, the form is filled out, faxed or mailed back, and the details are manually keyed in by people in our accounting department. Similarly, payments are mailed and the details are manually keyed in. There are 20 to 30 people working full-time as keyers for the thousands of documents which pass through accounting everyday.

On Monday, I attended a meeting with all of the members of the dev team + the top IT managers to discuss the direction of development of our software in 2009. I'm writing a web app which is intended to automate most of the processing above: users can buy and pay insurance online, and the web app will push data directly from the user to the database. The lag-time between buying insurance and making payments will drop from two or three weeks to a few milliseconds.

I really look forward to the new development, but I just had to open my mouth and ask during the meeting, "so what's going to happen to all of our keyers?". The response I got was a little more blunt than I expected, "we won't need them anymore".

3 months from now, when my software rolls into production, a boatload of jobs will be canned. Now that's depressing.

And, uh, Merry Christmas? Yeah, merry Christmas.

Financing transition and the love of money

Princess — Fri, 05 Dec 2008 12:42:00 GMT

To put this as blunt as I can, I am a miser. That's not an exaggeration -- many people know me for being so frugal that I forego basic "necessities" that most people take for granted: I don't own any furniture, I minimize the electric bill by sitting in the dark and refusing to turn on the AC/heater, I have the cheapest cellphone plan on the market, I don't have cable TV, I can feed myself for less than $3/day, I buy off-brand food and thrift-store clothing, and my entire wardrobe clothing consists of the following:

One pair of jeans for home, three pairs of slacks for work.
One shirt for home, two shirts for work.
One pair of tennis shoes for home, one pair of work shoes.
A few pairs of black socks, one coat, one belt.

That's just the tip of the iceburg, but you get the idea: I'm a money-motivated person. Its not the best personality trait to have, but my lifelong habits have allowed me to save a small fortune.

For the most part, the compulsion to hoard everything I earn is due to finance my transition. I made a conscious effort early in my life to accumulate as much money as possible to finance SRS and FFS as soon as possible. As a result, I tend to set pretty high bars for myself, and I have a tendency to job-hop to get higher salaries. To describe my recent job history:

- At 18, I worked from Apr '06 - June '07 at a grocery store for $7.50/hr.

- At 19, I worked from June '07 - Oct '08 as an entry-level computer programmer for $13/hr (an unacceptably low wage, by the way, even at my skill level). This job was intended to get my foot in the door to the IT world, just a stepping stone to better opportunities after I earned a year of work experience.

- At 21, I just signed a contract today as a .NET contractor making $27/hr, a respectable wage where I live. Every 6 months, I get a bonus equal to $2/hr * hours worked, which is otherwise equivalent to $29/hr.

Note: You'll notice there's a gap between Oct '08 and Dec '08 where I'm unemployed. The story behind that is kinda funny: I did not recieve any raises or reviews at my $13/hr job for the entire time I'd worked there, so I started applying for new jobs. A recruiting agency replied to my application, got me an interview with a major company in Omaha. I got a second interview which went really well. The recruiting agency said "good news, [company] wants to make you an offer this Friday", so I put in my two weeks notice. When that Friday came, I didn't get a call. I contacted the recruiters, and they told me that the company will make the offer next Wednesday instead. Well, I didn't get a call on Wednesday. I waited for the offer, but it didn't happen. By the time I found out the recruiting agency was feeding me bad information, I was no longer at my company.

I acted too hastily by quitting my job before I'd signed any papers saying I had another offer, and ended up unemployed for a month. We call this "jumping the gun", and I've learned a valuable character building lesson about quitting your job too soon as a result. I put my resume on Monster.com on November 14, and less than 3 weeks later I had two successful interviews, got an offer, signed my contract, and I start my new job on December 15 making twice as much as my previous employment.

It's extraordinarily difficult to be competitive in my line of work, especially given my age, the fact I have no degrees, and my relatively limited work experience. However, I was able to do well for myself through consistent hard work, smart planning, and maturity.

My objective is to save $30,000 this year. My budget for next year rounds out as follows:

- $27/hr * 2080 work hours per year = $56,160

- Less 21% that the government will tax away = $44,366

- Less $300/mo car payment = $40766

- Less $500/mo rent = $34766

- Less $100/mo food = $33566

- Less $40/mo phone + tax = $33086

- Less estimated $6000 to complete my 4-year degree by May = $27086

- Less $150/mo miscellaneous = $25286

This is a rough estimate, but it should be reasonably close. Excluding any bonuses I earn from my job, it looks like I'm going to be ~$5000 short of my objective, so I need an additional source of income to meet my objective. After I get my degree in May, I'll have some free time to get a part-time job. So, this gives me 7-8 months to earn $5000, or $625/mo. I want to work no more than 2 days a week, so need to find a part-time job which pays a minimum of $9.77/hr. I think I can do that.

If I balance my budget appropriate, pinch every penny as I'm already prone to doing, I should be able to finance my transition out-of-pocket, and I will be able to move things along very rapidly in the next 12 months. w00t!

Abusing IEnumberables in C#

Princess — Thu, 21 Aug 2008 17:00:00 GMT

The IEnumerable<> class is cool because it can be used to represent lazy lists. A lazy lists is just a sequence of data calculated on demand, rather than calculated at the time you create a list. Lazy sequences can represent arbitrarily large datastructures, even lists containing an infinite amount of data, without consuming an infinite amount of memory.

The match of IEnumerable comes from the yield operator, and it works thing like this:

        static void Main(string[] args)
        {
            IEnumerable<int> list = GetNumbers();
            IEnumerator<int> enumerator = list.GetEnumerator();

            Print(enumerator);
            Print(enumerator);
            Print(enumerator);
            Print(enumerator);
            Print(enumerator);

            Console.Write("\nPress any key to continue. . .");
            Console.ReadKey(true);
        }

        static void Print(IEnumerator<int> enumerator)
        {
            enumerator.MoveNext();
            Console.WriteLine("Print: enumurator.Current: {0}", enumerator.Current);
        }

        static IEnumerable<int> GetNumbers()
        {
            Console.WriteLine("GetNumbers: Returning 1");
            yield return 1;

            Console.WriteLine("GetNumbers: Returning 2");
            yield return 2;

            Console.WriteLine("GetNumbers: Returning 3");
            yield return 3;
        }

When you call GetNumbers(), you get an IEnumerable<int> back.

When you call MoveNext(), the code in the GetNumbers() method executes until it gets to the first 'yield return', then it returns from the method and assigns enumerator.Current to whatever what returned from the method. In this case, the first time you called MoveNext(), the function returns 1.

The next call to MoveNext() causes the GetNumbers() method to resume its execution on the line immediately following 'yield 1', it continues on until it hits 'yield 2'. Another call to MoveNext() resumes where it left off until it hits 'yield 3'.

Every 'yield' tells the method to pause execution, and every call to MoveNext() tells the method to resume execution from where it has paused.

The output of the program above is:

    GetNumbers: Returning 1
    Print: enumerator.Current: 1
    GetNumbers: Returning 2
    Print: enumerator.Current: 2
    GetNumbers: Returning 3
    Print: enumerator.Current: 3
    Print: enumerator.Current: 3
    Print: enumerator.Current: 3

Notice when the method finally exits and there is nothing left to yield, the enumerator.Current simply holds the last returned value of the function. Since the enumerator.MoveNext() method returns true if a value was yielded from the method, and false otherwise, we can enumerate manually through our list using a simple while loop:

        static void Main(string[] args)
        {
            IEnumerable<int> list = GetNumbers();
            IEnumerator<int> enumerator = list.GetEnumerator();

            while (enumerator.MoveNext())
            {
                Console.WriteLine("Print: enumurator.Current: {0}", enumerator.Current);
            }

            Console.Write("\nPress any key to continue. . .");
            Console.ReadKey(true);
        }

This prints:

    GetNumbers: Returning 1
    Print: enumerator.Current: 1
    GetNumbers: Returning 2
    Print: enumerator.Current: 2
    GetNumbers: Returning 3
    Print: enumerator.Current: 3

Of course, there's almost never any reason to enumerate manually through our list when we can use a foreach to do the same job:

        static void Main(string[] args)
        {
            foreach (int i in GetNumbers(5, 10))
                Console.WriteLine("i: {0}", i);

            Console.Write("\nPress any key to continue. . .");
            Console.ReadKey(true);
        }

        static IEnumerable<int> GetNumbers(int start, int max)
        {
            for (int i = start; i <= max; i++)
                yield return i;
        }

This prints:

    i: 5
    i: 6
    i: 7
    i: 8
    i: 9
    i: 10

Notice you can pass in parameters to your IEnumerable method and return a sequence of numbers. If you follow control flow of the program, notice that each item in the list was calculated on demand, rather than all at once; this is a lazy list.

Lazy lists are fascinating because they can, in principle, represent an infinite series of items. Here is an infinite list of primes:

        static void Main(string[] args)
        {
            IEnumerable<int> primes = Primes();
            IEnumerator<int> primeEnumerator = primes.GetEnumerator();

            Print(5, primeEnumerator);
            Print(7, primeEnumerator);

            Console.Write("\nPress any key to continue. . .");
            Console.ReadKey(true);
        }

        static void Print(int numberOfPrimes, IEnumerator<int> primeEnumerator)
        {
            Console.WriteLine("Next {0} primes", numberOfPrimes);

            for (int i = 1; i <= numberOfPrimes; i++)
            {
                primeEnumerator.MoveNext();
                Console.WriteLine(primeEnumerator.Current);
            }
            Console.WriteLine();
        }

        static IEnumerable<int> Primes()
        {
            int i = 1;
            while (true)
            {
                int max = (int)Math.Sqrt((double)i);
                bool isPrime = true;
                for (int count = 2; count <= max; count++)
                {
                    if (i % count == 0)
                    {
                        isPrime = false;
                        break;
                    }
                }

                if (isPrime)
                    yield return i;

                i++;
            }
        }

This prints:

    Next 5 primes:
    1
    2
    3
    5
    7

    Next 7 primes:
    11
    13
    17
    19
    23
    29
    31

Now, if we wanted to, we can really abuse the hell out of our prime generator by making it recursive and using it like a prime sieve.

        /*
        WARNING: the code above is for entertaniment purposely only.
        If you use this in production code, you will lose your job
        and shame your family.
        */

        static void Main(string[] args)
        {
            IEnumerator<int> primes = getPrimes().GetEnumerator();
            for (int i = 0; i < 20; i++)
            {
                primes.MoveNext();
                Console.WriteLine(primes.Current);
            }

            Console.Write("\nPress any key to continue. . .");
            Console.ReadKey(true);
        }

        static IEnumerable<int> counter()
        {
            int i = 2;
            while (true)
                yield return i++;
        }

        static IEnumerable<int> filter(int prime, IEnumerator<int> listen)
        {
            while (true)
            {
                listen.MoveNext();
                int i = listen.Current;
                if (i % prime != 0)
                    yield return i;
            }
        }

        static IEnumerable<int> getPrimes()
        {
            IEnumerator<int> myCounter = counter().GetEnumerator();

            while (true)
            {
                myCounter.MoveNext();
                int num = myCounter.Current;
                yield return num;

                myCounter = filter(num, myCounter).GetEnumerator();
            }
        }

This returns:
    2
    3
    4
    5
    11
    13
    17
    19
    23
    29
    ...

I have to give credit where credit is due: the inspiration the prime sieve implementation above is ripped from Rob Pike's talk on NewSqueak. I noticed that Pike used channels as sequence generators, which can be represented as IEnumerables in C#.

My code runs out of stack space after the first 50,000 primes of so. Pike's implementation, on the other hand, efficiently exploits a feature in NewSqueak that allows a programmer to literally replace the current stack frame with a call to another method (a remarkable feature to find outside of functional languages), a luxury that doesn't exist in C#.

This is an inefficient way to generate primes, but a remarkable exercise in generating sequences.

The Interview That Sucked

Princess — Wed, 13 Aug 2008 01:40:00 GMT

And it begins...

Every so often when you're searching for a new job, you find one or two companies that seem a little shady. You know if you submit an application, you're going to get an interview; and if you get an interview, you're going to get hired; and if you get hired, you're going to kill yourself in 3 months.

Most of us know what kind of red flags to look for when a job will really truly suck. I was not so informed.

When I was making the move from stocking shelves to professional programming, I started searching for entry-level programming positions. I happened across an ad for a small startup saying something along the lines of: "URGENT HELP NEEDED! Looking for 2 VB.Net Programmers With SQL Server Experience. ALL LEVELS OF EXPERIENCE CONSIDERED!!!!!"

Now, one of the red flags in any help wanted ad is the word "URGENT" in all caps. Another one is where the ratio of exclamation points to sentences exceeds a threshold of 1.75:1. But still, I decided I'd learn what this company was all about if it needed programmers so urgently; apparently they write ASP.Net content-management software used all over the world. Sounds fun, right? I applied at this job, and was asked to come into an interview a week later. I figure I have a shot because I have 7 years of prior web development of experience, used SQL Server 2000 and 2005 for the better part of 4 years, and have been working with VB.Net since 2003; I think I have the technical skill to fill an "ANY LEVEL OF EXPERIENCE CONSIDERED" position.

The Interviewees from Lala Land

When I get to the building, I'm directed to a waiting room. There are two other guys there who have applied for the same position. One of the guys is a grizzled, older-type fella; the other was a young guy, early 20s, and very sharply dressed -- wearing what appeared to be a tuxedo, actually.

I really hate sitting in quiet rooms with other people, so I make small talk with these guys. I ask the older guy about his programming experience, and he makes a comment that he last worked on an old COBOL system sometime in 1987; afterward, he was a mechanic, but was laid off; and presently he works in a factory assembly line screwing plastic caps on bottles of shampoo. Sweet mother of Christ, what a sad story. What kind of mistakes in your life do you have to make to slide from software developer, to mechanic, to screwing caps on bottles for a living? One thing's for sure: this guy is no threat to me; he has no relevant work experience.

Tuxedo guy introduces himself as a college student at one of the nearby universities, and I make a comment that he is remarkably well-spoken for a college student. He replies that he was a national champion in a public speaking / forensics competition (it certainly shows). I start talking to him about programming, and then I notice he's looking at me with the most idiotic dog-faced expression I've ever seen in my life. I decided to test Tuxedo guys technical knowledge:

Do you at least know SQL?
"Nope."

Are you familiar with object oriented programming? For example, do you know what a class is?
"Nope."

Have you ever heard of the word 'boolean'? Do you know what variables are?
"I think so, its kinda like Java, right?"

Fuck me sideways! Somehow I managed to keep myself from falling on the floor laughing. Tuxedo guy was beyond clueless. Utterly, appallingly braindead.

The interview gods were clearly smiling upon me: on the one hand, I have Shampoo Lid whose 20-year outdated expertise is overshadowed by his career as a professional screw capper, and Tuxedo guy who can't tell the difference between a fast fourier transformation and a bifunctor catamorphism on a monoidal category.

The Interview

After a few minutes of chit-chat, I man asks all three of us in the waiting room to join him in an office for the group interview.

Group interview? I've heard of these things. These are the kinds of interviews where an interviewer asks a question like "why are you better than the guy to the left of you" and you have to try topping the answers of everyone around you. I've NEVER heard of anything good coming out of these interviews, and I consider them to be deeply unprofessional. Normally, I would just say "sorry, I'm not going to play any games during this interview" and walk out, but given my opponents Shampoo Lid and Tuxedo guy, I figured there's no point passing up an interview that I will definitely "win".

In the interviewing room, there are two other interviewers. Apparently, all three of us were going to interviewed by these three judges. Weird. I've never seen or heard of this before.

Everyone sits down and the judges ask Shampoo Lid the basic interview questions: "where do you see yourself in 5 years", "what can you contribute to the company", "why did you leave your last job", etc. Altogether, this question/answer session lasts about 10 minutes. It was a very mundane, even boring interview.

I'm next. The judges pull out a copy of my resume. They make a comment that some parts of it were not very clear --- and to a certain extent, they were right. I'd never written a resume or applied for a technical position before, so it was probably not the best resume ever written. They ask me an odd question: "what do you mean when you say you have experience writing software for end-users". The judges basically read a sentence from my resume and asked to explain it... I'm not really sure what they need explaining, it says I have experience writing end-user software, what else can I say? The judges prod me for an answer, so I explain to them that there is all different kinds of software, such as end-user software, middleware, system software, and all of these different tiers of software require different skills to pull off effectively. Applications like Notepad vs SQL Server vs ethernet drivers vs system kernal represent software in each different tier, and my specialization is writing applications that your average computer user interacts with on an everyday basis. I thought I gave a decent answer, at least one that shows off my technical knowlege.

The judges precede to the next sentence in my resume and ask me to explain it. And then they asked me to explain the next sentence. And the next one. They read my resume out loud word for word and asked me to explain every sentence. Seriously, they asked me "what does 'O'-'O'-'P' mean here?" It was pathetic. My "interview", consisting of the judges regurgitating every line of my resume back at me, lasted 6 minutes. 7 tops. It was embarrassing and pathetic.

The judges talk to Tuxedo guy last. They start by commenting on how well he was dressed, and Tuxedo guy makes a comment about wearing the same outfit that he wore when he won his speech competition. He goes off on a tangent about how, after he won, he earned a scholarship to help pay for a missionary trip to Africa. He talks about how he's known his girlfriend since elementary school, how much he likes bathing dogs, and just all sorts of irrelevant anecdotes. Not a single moment of his 40 minute interview did he say anything about writing code.

After everyone interview, the judges leave the room for a few minutes. They come back and thank Shampoo Lid and I for our time; however, they say to Tuxedo Guy, "we think you'll fit in really well here, and we'd like to make you an offer". I was absolutely furious, I swear to god I was ready to start cracking skulls and breaking bodies. The interview was an embarrassing, mocking waste of my time.

Job Hunting Again

Back to the job search. I noticed the ad at the software company I interviewed for that day had been updated to say "Looking for 1 VB.Net Programmers With SQL Server Experience". Eventually, the ad disappeared altogether.

It took about a month, but I was fortunate enough to apply for a different job and get an interview, which went extremely well. This interview was extremely technical in nature, consisting of questions like "heres a database schema, now write a query to get this set of data", instead of bullshit throwaway questions like "where do you see yourself in 5 years". I nailed the interview and got the job.

Now, I normally heed the advice, "as soon as you find a job, start looking for a new one" just a safety net; I don't plan on getting fired from my jobs, but it helps to know who's hiring and whats in demand just in case.

So, as I'm paging through job listings, I come across a help eerily familiar help wanted ad from the same small startup company who royally fucked up interview 4 weeks prior: "URGENT HELP NEEDED! Looking for 2 VB.Net Programmers With SQL Server Experience. ALL LEVELS OF EXPERIENCE CONSIDERED!!!!!" I laughed so hard I shat myself.

Communicating Between User Controls In ASP.Net Pages

Princess — Sun, 10 Aug 2008 03:02:00 GMT

In general, when I'm creating websites in ASP.Net, I tend to create a lot of user controls. More or less, all of the user interface of embedded in user controls, so that I can encapsulate and reuse specific functionality on any page of my website.

For example, lets say I have a screen that asks a user to login: on a successful login, the screen displays a welcome message to the user. I would create two user controls, one for the login panel and one for the welcome message, and display them like this:

The diagram above is a fairly simple layout, and a fairly typical way of designing controls. You might imagine that, on a successful login, the LoginPanel disappears, and the WelcomeMessage displays something along the lines of "Welcome, Bob! You have two new messages."; maybe on an unsuccessful login, the WelcomeMessage displays something along the lines of "Oops, wrong username or password."

Since our LoginPanel is contained in its own usercontrol, it does not know of the existence of the WelcomeMessage control; since the WelcomeMessage usercontrol is also self-contained, it does not know about the LoginPanel. Yet, we have to make the WelcomeMessage change its state when a user is successfully authenticated from the LoginPanel -- somehow, our LoginPanel and WelcomeMessage controls need to communicate with one another.

Here is some sourcecode to show the problem in a more concrete sense:

-----------

LoginPanel.ascx

<%@ Control Language="C#" ClassName="LoginPanel" %>
<script runat="server">
    public bool IsAuthenticated
    {
        get
        {
            return ViewState["IsAuthenticated"] == null
                ? false
                : (bool)ViewState["IsAuthenticated"];
        }
        private set
        {
            ViewState["IsAuthenticated"] = value;
        }
    }

    protected void btnLogin_Click(object sender, EventArgs e)
    {
        IsAuthenticated =
            (txtUsername.Text == "user" && txtPassword.Text == "secret");
    }
</script>

<div>
    Username: <asp:TextBox runat="server" ID="txtUsername" /><br />
    Password: <asp:TextBox runat="server" ID="txtPassword"
                TextMode="Password" /><br />
    <asp:Button runat="server" ID="btnLogin" Text="Login"
        onclick="btnLogin_Click" />
</div>

WelcomeMessage.ascx

<%@ Control Language="C#" ClassName="WelcomeMessage" %>
<script runat="server">
    public void SetMsg(string msg)
    {
        lblMsg.Text = msg;
    }
</script>

Default.aspx
<%@ Page Language="C#" %>
<%@ Register src="LoginPanel.ascx" tagname="LoginPanel" tagprefix="uc1" %>
<%@ Register src="WelcomeMessage.ascx" tagname="WelcomeMessage" tagprefix="uc2" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
        <uc1:LoginPanel ID="LoginPanel1" runat="server" />
        <uc2:WelcomeMessage ID="WelcomeMessage1" runat="server" />
    </form>
</body>
</html>

-----------

(The WelcomeMessage control is admittedly pretty lame.)

So, we have two user controls. When a user logs in, we need to display the correct view in mviewControlPanel and set the welcome message appropriately. Now, there are a few "obvious" solutions to this problem; I'll run through a list of possible solutions and comment on them:

#1) You could simply check the LoginPanel1.Authenticated property on Page_Load, and set everything appropriately. For example, on Default.aspx, you could replace the Page_Load event with the following:

    protected void Page_Load(object sender, EventArgs e)
    {
        if (Page.IsPostBack)
        {
            if (LoginPanel1.IsAuthenticated)
            {
                LoginPanel1.Visible = false;
                WelcomeMessage1.SetMsg("Hello, User!");
            }
        }
    }

That looks like it should do the trick, but it doesn't actually work because the code exceutes in the wrong order. Oops! The ASP.Net page life cycle processes the events in the following order:

- Default.aspx.Page_Load
- LoginPanel.aspx.btnLogin_Click

Since the Page_Load event reads the IsAuthenticated property *before* it gets assigned, your page processes incorrectly.

#2) To solve the the little "events not executing in the right order" problem above, you might be tempted to move the code above out of the Page_Load event, and into the Page_PreRender event so that it happens later in the page lifecycle.

This works, but its a notoriously bad work around. The Page_PreRender event gets called on every postback, and its not reasonable to check the LoginPanel.IsAuthenticated variable and re-setup all of the dependent user controls everytime. Setting up a user control for Authenticated/Unauthenticated mode might require a number of database queries or heavy data processing of some kind.

Additionally, this solution simply scale very well. If we had a large number of interacting controls, the Page_PreRender event would begin to get very bloated. Similarly, if we had a requirement to make the WelcomeMessage talk back to the login control (for example, by putting a logout button in the WelcomeMessage), it would simply be a nightmare to program correctly: on the one hand, you hide the LoginPanel when its IsAuthenticated property is true, on the other you show the LoginPanel when the WelcomeMessage's LoggedOut property is true. What happens when a user logs in, then logs back out? How do you know which order to check the variables?

Ideally, when a user logs in (or logs out), you want all of your controls to respond appropriately on demand.

#3) We want the WelcomeMessage text to be set on demand whenever we log in, so the WelcomeMessage needs to respond to an event raised by the LoginPanel. Since ASP.Net is an event-driven language, its trivial to create an event handler

    public event EventHandler UserLoggedIn;

    // ,..

    protected void btnLogin_Click(object sender, EventArgs e)
    {
        IsAuthenticated =
            (txtUsername.Text == "user" && txtPassword.Text == "secret");

        if (UserLoggedIn != null)
            UserLoggedIn(this, EventArgs.Empty);
    }

Now, we can wire up Default.aspx to this event handler:

<%@ Page Language="C#" %>
<%@ Register src="LoginPanel.ascx" tagname="LoginPanel" tagprefix="uc1" %>
<%@ Register src="WelcomeMessage.ascx" tagname="WelcomeMessage" tagprefix="uc2" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
        <uc1:LoginPanel ID="LoginPanel1" runat="server"
            OnUserLoggedIn="LoginPanel1_UserLoggedIn"/>
        <uc2:WelcomeMessage ID="WelcomeMessage1" runat="server" />
    </form>
</body>
</html>

The event-driven approach is definitely superior to the methods enumerated above: we change the state of our WelcomeMessage the very moment we click the 'login' button, and we don't have to worry about the page lifecycle. Additionally, if the WelcomeMessage needed to trigger some kind of response in the LoginPanel.aspx control, we could just create an event on WelcomeMessage, catch it on Default.aspx, and call the right methods LoginPanel.

Notice that LoginPanel and WelcomeMessage do not talk directly to one another. Since they don't know about each others existence, the web page itself acts as a kind of proxy to channel communication from one control to the next.

Now, while the code above looks pretty good, it is not scalable in the least:

- Since the web page is our proxy, we can only we can only notify WelcomeMessage of events triggered in LoginPanel through WelcomeMessage's public methods. This forces us to expose a lot of implementation detail to our web page whenever we need two controls to communicate.

- The example above is somewhat contrived because LoginPanel and WelcomeMessage located on the same container. In the real world, there are probably going to be multiple layers of containers between your LoginPanel and your WelcomeMessage control, similar to this:

It is too cumbersome and tedious to raise your UserLoggedIn event up through all of its parent user controls, then pass the information back down through all of the nested user controls. As a result, your pages become bloated with code to pass events up and down through controls, and your pages become difficult to modify because moving or deleting any control on your website causes a compilation error.

- What if, for some reason, you wanted to add another control, such as a NewMessages control, which listened for the UserLoggedIn event? Well, now you have to write more code to funnel events to the WelcomeMessage control and NewMessages control at the same time.

- Even the graphic above is too generous. For example, if your LoginPanel control is on a master page, and your WelcomeMessage control is on a child page, you don't have the luxury of even knowing what controls exist on a page to funnel messages through, you don't even know if an instance of WelcomeMessage exists to handle your events.

Hopefully now we can see the problem with the method above. We need a more robust message-passing interface to satisfy the following conditions:

- We don't want to go through hierarchies of controls. No matter where controls are placed on a page, no matter how deeply nested inside other controls they are, we never want more than one proxy of communication between any two controls at a time.

- We cannot assume that our controls are conveniently embedded into our user interfaces at design time, rather than dynamically created on the fly at runtime.

- We do not want to expose the internal implementation of our controls if we can avoid it.

- We need to accomodate new controls who need to listen for events transparently; that is, without needing to change any lines of code in our message-passing interface

#4) We can satisfy all of the requirements above very easily if we just think about the problem a little differently. It really helps to seperate out message-passing logic from our user interface, so we should create a class which serves the role as a proxy between our LoginNotifier and any other controls:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.SessionState;

namespace Notification
{
    public interface ILoginListener
    {
        void NotifyUserLoggedIn(bool authenticated);
    }

    public class LoginNotifier
    {
        public static LoginNotifier SessionInstance
        {
            get
            {
                HttpSessionState session = HttpContext.Current.Session;
                if (session["LoginNotifier"] == null)
                    session["LoginNotifier"] = new LoginNotifier();

                return (LoginNotifier)session["LoginNotifier"];
            }
        }

private LinkedList<ILoginListener> notifiers = new LinkedList<ILoginListener>();

private LoginNotifier() { }

        public void Register(ILoginListener listener)
        {
            notifiers.AddLast(listener);
        }

        public void Unregister(ILoginListener listener)
        {
            notifiers.Remove(listener);
        }

        public void Notify(bool authenticated)
        {
            foreach (ILoginListener listener in notifiers)
                listener.NotifyUserLoggedIn(authenticated);
        }
    }
}

Now we have an adequate proxy to notify controls of the UserLoggedIn event. To use this class, we need to re-write the LoginPanel.btnLogin_Click event as follows:

    public bool IsAuthenticated
    {
        get
        {
            return ViewState["IsAuthenticated"] == null
                ? false
                : (bool)ViewState["IsAuthenticated"];
        }
        private set
        {
            ViewState["IsAuthenticated"] = value;
        }
    }

    protected void btnLogin_Click(object sender, EventArgs e)
    {
        IsAuthenticated =
            (txtUsername.Text == "user" && txtPassword.Text == "secret");

Notification.LoginNotifier.SessionInstance.Notify(IsAuthenticated);
}

Now, we need to register WelcomeMessage.ascx with the notifier. I'd prefer to implement the ILoginListener interface on my control; however, since I originally wrote the WelcomeMessage.ascx file using inline script blocks, but I want to provide my own constructor and implement an interface, which means I need to convert to the code-behind model.

WelcomeMessage.ascx:

<%@ Control Language="C#" AutoEventWireup="true"
CodeFile="WelcomeMessage.ascx.cs" Inherits="WelcomeMessage" %>
<div>
<asp:Literal runat="server" ID="lblMsg" />
</div>

WelcomeMessage.ascx.cs:

using System;
using System.Web.UI.WebControls;
using Notification;
public partial class WelcomeMessage : System.Web.UI.UserControl, ILoginListener
{
    public WelcomeMessage()
    {
        LoginNotifier.SessionInstance.Register(this);
    }

    public override void Dispose()
    {
        LoginNotifier.SessionInstance.Unregister(this);
        base.Dispose();
    }

    public void NotifyUserLoggedIn(bool authenticated)
    {
        string msg = authenticated
            ? "Welcome, User!"
            : "Bad username or password";
        SetMsg(msg);
    }

    private void SetMsg(string msg)
    {
        lblMsg.Text = msg;
    }
}

Everything simply works like magic. My default.aspx page never needs to know or care about the LoginPanel or the WelcomeMessage controls anymore. More imporantly, this code is reusable; an indefinite number of controls can register themselves with this notifier, and I don't need to add any new code to pass messages up and down through any control hierarchies whatsoever.

As of right now, if we wanted to create a new event to listen on, we'd have to create a new interface and listener class. There are a lot of ways to make the pattern above a little more generic and reusable, for example:

public class Notifier
    {
        public static Notifier SessionInstance
        {
            get
            {
                HttpSessionState session = HttpContext.Current.Session;
                if (session["EventNotifier"] == null)
                    session["EventNotifier"] = new Notifier();

                return (Notifier)session["EventNotifier"];
            }
        }

private Dictionary<string, EventHandler> eventPool;

        private Notifier()
        {
            eventPool = new Dictionary<string, EventHandler>();
        }

        public void Register(string eventID, EventHandler handler)
        {
            EventHandler temp;
            if (eventPool.TryGetValue(eventID, out temp))
                eventPool[eventID] = temp + handler;
            else
                eventPool.Add(eventID, handler);
        }

        public void Unregister(string eventID, EventHandler handler)
        {
            EventHandler temp;
            if (eventPool.TryGetValue(eventID, out temp))
            {
                temp -= handler;
                if (temp != null)
                    eventPool[eventID] = temp;
                else
                    eventPool.Remove(eventID);
            }
        }

        public void Notify(string eventID, object sender)
        {
            Notify(eventID, sender, EventArgs.Empty);
        }

        public void Notify(string eventID, object sender, EventArgs e)
        {
            EventHandler temp;
            if (eventPool.TryGetValue(eventID, out temp) && temp != null)
                temp(sender, e);
        }
    }

The class above allows a client to register named events. For example:

Notifier.SessionInstance.Register("UserLoggedIn", SomeEventHandler);

There are many variations on the pattern above, such as notifying listeners asyncronously, using generics to pass more specific type information than the EventArgs base class, etc.

As a final note: none of the code above is threadsafe. Make sure that you put locks around any code that adds, removes, or enumerates through items in a collection.

Beautiful Code and The Beast

Princess — Wed, 06 Aug 2008 22:37:00 GMT

I’m one of those programmers who emphasizes heavily on the aesthetic appeal of code. I describe certain pieces of well-written code as beautiful and elegant, and poorly written code as ugly or dirty. I like Eric Raymond’s explanation of beautiful code:

Writing these [large Perl programs of significant complexity] left me progressively less satisfied with Perl. Larger project size seemed to magnify some of Perl’s annoyances into serious, continuing problems. The syntax that had seemed merely eccentric at a hundred lines began to seem like a nigh-impenetrable hedge of thorns at a thousand. “More than one way to do it” lent flavor and expressiveness at a small scale, but made it significantly harder to maintain consistent style across a wider code base. And many of the features that were later patched into Perl to address the complexity-control needs of bigger programs (objects, lexical scoping, “use strict”, etc.) had a fragile, jerry-rigged feel about them.

These problems combined to make large volumes of Perl code seem unreasonably difficult to read and grasp as a whole after only a few days’ absence. Also, I found I was spending more and more time wrestling with artifacts of the language rather than my application problems. And, most damning of all, the resulting code was ugly—this matters. Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.

The elegance of code seems to coincide with its readability, brevity, and intuitively obvious implementation.

The Ultimate Measure of Software is User Experience

From a realistic point of view, the ultimate goal of writing software should be to satisfy users. Users only care about their user experience, they couldn’t care less what your beautiful code looks like.

Its tempting to think that there’s no point to writing elegant code if users are never going to appreciate it. I used to agree with this sentiment before I started developing software professionally, before I really saw the effects of bad code in the real world.

Thank you, come again

Every year, my company attempts to start selling a new piece of banking software. Two years ago, the company wrote up specs on a piece of teller software, eTeller [actual name of software changed to project job], and decided it would be easiest to outsource this software to contracters in India. Our relationship with India was simple: my company would make the business decisions and request features, and India would deliver the code.

After a year of unsupervised development, we started selling version 1.0 of eTeller. As we expect in the normal lifecycle of any software, we got bug reports, enhancement and new feature requests, etc. India was happy to make the changes...

... until around 6 months into the project when India began to slip; they simply weren't able to keep pace with the change requests. After v1.0 was installed, the list of known bugs was on the rise, development of new features came to a stagnant halt, and user satisfaction was taking a dive. The application had serious stability problems, such as crashing or freezing 40 to 50 times a day (not an exaggeration) and a general inability to keep cash drawers balanced.

When bank presidents started putting the president of my company on speed-dial to demand bug fixes or threaten to find a new software vendor, we realized we had a problem. Since India was unable to make changes to the software, we decided that we simply couldn't rely on India to do their jobs right; we requested access to their sourcecode repository to make the changes ourselves. And that’s when we saw it for the first time:

The Beast

Every programmer will eventually encounter The Beast: an application exceeding 10,000 or 100,000 or 1,000,000 lines of the worst, most twisted, most utterly evil, fantastically wicked, atrociously written code on the planet.

These multi-megabyte monsters are born when large companies attempt to save a few pennies by hiring unskilled amateurs to do professional work. Beasts often rear their heads most often in mission-critical systems such as banks, hospitals, insurance companies, air-traffic controllers, grocery stores, routers.

Even for a Beast, eTeller was a fright to behold. Here is a brief list of evil:

More than 130,000+ lines of tangled, completely unmodularized C#.
Excluding form files, there were only 2 classes used in the entire application:
1) A static class called “Globals”, which held 1000s of variables to maintain the state of application. There were no other datatypes used in the Globals class apart from bool, string, decimal, and dataset.
2) This SQLHelper class copy/pasted from the internet.
20,000 lines of code embedded in a single file called frmMain.cs. All other code in the application accessed frmMain directly in this fashion:
```
((frmMain)this.MDIParent).UpdateStatusBar(hstValues);
```
To look up accounts, the programmers did something like this:
```
bool blnAccountExists =
    new frmAccounts().GetAccountInfo().blnAccountExists
```
As bad as it already is creating an invisible form to perform business logic, how do you think the form knew which account to look up? That’s easy: the form could access Globals.lngAcctNum and Globals.strAcctType. (Hungarian notation? What is this, 1997 all over again?)
Parameters were rarely passed between functions, since all state was held in the Globals class. In the rare instance that parameters were passed, they were passed as strings for convenience.
Nearly all methods and functions had side-effects, no matter the purpose the function, usually modifying 1 or more variables in the Globals namespace. For example, one of the form validation methods had a mysterious side effect of calculating over and short payments on loans for whatever account was stored Globals.lngAcctNum.
Some forms had invisible labels. The programmers used the .Text and .Tag properties to hold miscellaneous data.
No objects existed in the application. The only datastructures used were ArrayLists, HashTables, and DataSets — none of which guarantee type safety. The programmers actually invented bizarre pseudo-objects using just ArrayLists, HashTables, and DataSets:
- ArrayLists of hashtables
- HashTables using arraylists as keys and other hashtables as values
- Arraylists of arraylists
- HashTables using DataRows as keys and ArrayLists as values
For a static Accounts class in particular, the programmer created a seperate HashTable for each concievable property of an account: a HashTable called hstAcctExists, hstAcctNeedsOverride, hstAcctFirstName.

The keys for all of those hashtables was a “|” seperated string. Concievable keys included “123456|DDA”, “24100|SVG”, “100|LNS”, etc. (Most of these hashtables were easy to convert to typed Dictionary objects at first, and eventually into a unified Account object.)
CTRL-C, CTRL-V was a favorite key combination employed by India. For example, the 500 lines of code required to print receipts was copied across 7 forms. The code required to implement the "customizable grid" feature was copy/pasted verbatim across 12 different forms.
There was an unusual threading model, which I call the Thread-And-Timer model. Every form that used threading had 1 or more timers on it (1 timer per thread). The Thread-And-Timer model looks like this:
```
bool finished = false;
Thread backgroundThread;
public void SomePublicMethodThatsEnevitablyInvokedRandomlyByAnotherForm()
{
     try
     {
         backgroundThread.Abort();
     }
     catch { // swallow }
     finished = false;
     backgroundThread = new Thread(someMethod);
     timer1.Enabled = true;
}

publiv void someMethod()
{
    // do stuff in the background
    finished = true;
}

private void timer1_Tick(object sender, TimerEventArgs e)
{
    try
    {
        if (finished == true)
            backgroundThread.Abort();
    }
    catch { // swallow }
}
 
```
Each time you click a button, it would start a new thread. If you click the button before the thread finishes its job, then the thread is aborted so that another new job is started. After starting a thread, a timer would check some bool at intervals of 100 milliseconds. When the bool is set to true, the timer aborts the thread for some reason and the resulting ThreadAbortException is ignored.

This bizarre pattern was found in a dozen different places throughout the application. Naturally, every thread in the application freely accessed any variable, including the ones in the Globals class, without locking.
Spectacular abuse of the ternary operator. Here are some actual snippets of code pulled from the application:

strDrCr = chkCredits.Checked && chkDebits.Checked ? string.Empty : chkDebits.Checked ? "D" : chkCredits.Checked ? "C" : "N";

if (strDefaultVals == strNowVals && (dsTranHist == null ? true : dsTranHist.Tables.Count == 0 ? true : dsTranHist.Tables[0].Rows.Count == 0 ? true : false))

if (Validations(parPostMode == "ADD" ? true : false))

That is only a small tip of the iceburg, barely a fraction of all of the errors in eTeller. The most damning part of the application was the total absence of unit tests. Not a single test, for a single one of the 130,000 lines of code. It was evident why the programmers were unable to make changes.

Crisis-Driven Development

After seeing the state of eTeller’s ugly code, my dev team became heavily involved with the development and maintenance of this application. From Nov 2007 to Jan 2008, we entered a state of crisis-driven development.

Banks were demanding to have bugs fixed on the same day they were reported. Each new bug sent us into crisis-mode: we fixed bugs as fast as possible and send a new release to QA almost immediately. Inevitably, 5 new bugs would be documented within minutes of QA testing, so we’d fix those up as quickly as possible.

Against the recommedations of QA and developers, we were releasing new versions of eTeller once every 2 to 3 days for a couple of months. There were many occasions where we’d be writing bug fixes to a release minutes before updates at a bank.

Over time, we stablized our product just enough to add new features and respond to bug reports at a reasonable pace. eTeller is continuously being refactored, piece by piece, into a better application everyday.

What did I learn from The Beast

While my team was working on eTeller, I discovered how ugly code has a psychological effect on programmers. The amount of frustration working with the code simply sucks the vitality out of programmers, it makes programmers ashamed of their own creations. Unhappy programmers don’t produce quality code or good tests, which holds back the development of application in the long run. Unahppy programmers tend to look for new, less stressful jobs, which also hurts development.

My team has been hacking through the jungle of eTeller code since Nov 2007. We’ve made significant improvements (especially with regard to type-safe objects and seperation of business logic from UI). We’ve re-written about 25% of the code in eTeller (which, fortunately, corresponds to about 90% of the core eTeller functionality) to the point where the code is marginally palatable. The application line-count is down to around 53,000 non-trivial lines of code, and drops at a rate of 20kb per week. We estimate the final 'gold' version of this application will drop to around 25,000 non-trivial lines of code.

Don’t let anyone tell you that the beauty of code does not matter to users. High quality code, more often than not, corresponds to a high quality product and satisfying user experience. If programmers want to satisfy our users, then we’re obliged to write high quality, beautiful code in all of our applications.

(In case you're wondering, we eventually terminated our contract with India.)

Jesus Who? (Redux)

Princess — Mon, 04 Aug 2008 20:47:00 GMT

Yesterday's post Jesus Who was so full of awesome and win, I decided to give it another go:

Jesus was a demon: I have talked to jesus. I was baptised catholic. Spoke with the angels in the cathedrals, they taught me how to pray. Then I found out jesus was a demon. He's a very big one, a warden in the prison that contains the demons. And if you want the life of comfort, then bow down to him, worship him and swear to abort and exclude other demons, and he will give you pleasure and comfort. But stand up and fight him, and he fights just like a demon.

Jesus never existed: For most of my life, I had taken it for granted that Jesus, although certainly not a god, was nevertheless an historical personage - perhaps a magician skilled in hypnosis. To be sure, I knew that some of the world's greatest scholars had denied his existence. Nevertheless, I had always more or less supposed that it was improbable that so many stories could have sprung up about someone who had never existed.

Jesus died of a blood clot: An Israeli researcher has challenged the popular belief that Jesus died of blood loss on the cross, saying he probably succumbed to a sometimes fatal disorder now associated with long-haul air travel.

Professor Benjamin Brenner wrote in The Journal of Thrombosis and Haemostasis that Jesus's death, traditionally believed to have occurred 3-6 hours after crucifixion began, was probably caused by a blood clot that reached his lungs.

Jesus wants to eat your soul: Does God love you? Of course not.

God hates you; but God is hungry and needs you to help Him eat your soul. He chuckles to himself that He cannot only suck out your life and being, but He can make you believe the lie as well.

The remaining items are a list of messianic theories collected a few years ago by a poster on the Randi.org forums by the name of Dr Adequate (clicky):

Jesus hates fags and environmentalists, votes Republican: So how would Jesus vote? I believe that Jesus would have issues with some of the liberal stances. I don't think Jesus would under any circumstances tell any woman, "It's OK to have an abortion this time." I don't think Jesus would agree with homosexuals having any rights simply due to the fact that they choose to be homosexual. Lastly, I'm pretty sure Jesus would want prayer in school, and His commandments in every courtroom.

So to answer your question, I believe Jesus would vote Republican. And I believe His response to your global warming fear would be, "Don't worry, I am in control and I don't need to rely on you to 'save the planet.'"

Jesus supports public prayer, whatever he may have said in the gospels to the contrary (dead link): I am sure Jesus would vote Republican because he would is against abortion, supporting people who refused to support themselves, he is into investing wisely, public prayer, and standing up for the 10 commandments.

Jesus is against public healthcare because it's a blasphemous interference with god's plan. Private health care isn't, for some reason (dead link): Jesus did not come to earth to offer free medical care. He used healing as a way to prove His Godliness to those He wanted to so that people would be drawn to Him as Lord and Savoir. He also fed the hungry for the same reason... As to health care entitlement, where do you see that in the Bible? It is not there. The Bible is full of stories of suffering and death, as the natural consequence of our sinfullness. If along the way you are able to ease your suffering or cure your illness due to God's gift of medicine to our world, that is fine, but no where does the Bible state that it is available to all nor that life should be extended beyond God's planned timing, because of our lack of faith in the gifts of heaven that await us after we leave this earth.

Jesus likes small government : Jesus was all about 'less' government (Church) in man's life...That's not very 'democrat', is it?

Jesus supports a flat rate income tax, hates "demon scum rats": Would Jesus steal? Ask others to covet what "the rich" have? Would he condone murder of innocent children in partial birth abominations? Would he put up government as a god to be worshipped? How many of the 10 commandments can a democrat break before rolling out of bed?

Governments are supposed to be subject to God. Blessed is the nation whose god is the Lord. The king is supposed to hand write a personal copy fo the Bible for his his personal use - to keep it fresh in his mind. . He is not supposed to screw around with every intern and rape women. He is not supposed... ok enough already... The govt is supposed to get by on a flat 20%.... but don't let facts or truth get in the way of these demon scum rats.

That's everything I can find on Jesus. I am still looking for:

Jesus was from Michigan

Jesus was a Jiffy Lube employee

Jesus was a Klingon (although this is close)

Jesus was a bitch (a lover, a child, a mother, a sinner, a saint...)

Jesus was an embryo

Jesus Who?

Princess — Mon, 04 Aug 2008 01:22:00 GMT

Who was Jesus? Lord and savior of the world? That's only half the story...

Jesus was gay: Some commentators argue from silence. They note that there is no passage in the Christian Scriptures (New Testament) that directly describes anything about Jesus' sexuality. There are many direct and indirect references to Jesus' sensuality. He was accused of being a "drunkard and a glutton" and of partying with "prostitutes and sinners." He apparently enjoyed a tender foot massage from a woman. Yet, neither Jesus' sexuality nor his celibacy is mentioned. Yet, sex is referred to, elsewhere in the Bible, quite often. One might argue that the books in the Christian Scriptures might have once described Jesus' sexual relationships, but that these passages have been vigorously censored by the later church because they were unconventional.

Jesus was a Buddhist: Jesus had expounded his doctrine of patience, non-violence and compassion which was seemingly an opposite view to that of the God according to the Old Testament. Jesus preached and asked his followers to turn the other cheek when somebody slapped you, whist an eye for an eye and a tooth for a tooth in the Mosaic Law clearly denoted retaliation and vengeance which were regarded as justice.

Jesus was black: And lastly, by making Christ Black, it identified him with oppressed Black folks. For in all of religious history Christ had always sided with the poor, the downtrodden and disenfranchised. His ministry was one of liberation. Since Blacks have been on the receiving end of white racism, it stands to reason that Christ, not only identified with their plight but became their image and likeness.
There is sound reason to believe that Jesus Christ was Black.

Jesus was a democrat: I have also heard that President Bush now has political currency. He has a strong majority that has a clear mandate. Supporters of the President have demanded religion over rhetoric. These opinions made me think, “What would Jesus do?” I am not a biblical scholar so I pulled out a Bible. I couldn’t believe what I found! Jesus was a democrat!

Jesus was a woman: A publisher is touting a new edition of the Gospels that identifies Christ as a woman named Judith Christ of Nazareth.

LBI Institute says its version, Judith Christ of Nazareth, The Gospels of the Bible, Corrected to Reflect that Christ Was a Woman, Extracted from Matthew, Mark, Luke and John, takes Thomas Jefferson's edited Gospel one step futher by "correcting" the gender of Christ and God.

Jesus was a witch: If Jesus were here today, he would be a witch! No single one of these reasons prove the Witchiness of Jesus; but taken as a whole, they make for a compelling case.

Jesus was a white nationalist: God hates therefore I hate. God only cares about the Adamic white race therefore I only care for the Adamic white race, bastard.

Jesus was a Hindu: Christianity has changed in the past three hundred years and is still in a state of flux. You must realize that Jesus Christ did not write the Bible, which was written a couple of centuries after the death of Jesus. Old Testament was opposed by Jesus and yet the Christians accepted it. In my opinion Jesus was a Hindu saint who was persecuted in the land of his birth. His followers made some compromises with the ruling classes and built a religion. The renaissance brought Christianity closer to Hinduism as I understand it. Please download my article "Hinduism - A global Religion of the Modern World" to read more about it.

Jesus was an anti-Semite: Since Jesus called the Jews of his day liars, vipers, sons of Satan, etc., you should also consider Jesus antisemitic. Consequently, you should immediately cease and desist trying to claim Jesus was Jewish. Jesus was not a Jew; Jesus was an antisemite.

Jesus was Hitler (spoof): Jesus is an evil, anti-Semitic coward. Just look at how fake he is. He claims to be the son of "God", and that he stands for good will towards men, but what he doesn't want you to know is that he is God's diabolical prodigal son. He spends all of his spare time killing Jews and punching babies. He tricked us all into believing that he was the "messiah", and that him being crucified was merely a sacrifice to absolve mankind for all of their sins. When in reality he was crucified by the Jews as a result of years of showboating and being a straight up dick.

Jesus first developed his severe hatred of Jews when he submitted a dreidel with a swastika painted on one of the four sides. The idea was rejected by the Jewish community because they thought the symbol was "stupid" and this hurt Jesus's feelings. The swastika was later used by Jesus as Hitler and is now known as a symbol of hatred toward Jews.

Jesus was an alcoholic: Kissing the nape of my neck,
I can smell the whiskey on his beard.
Jesus was an alcoholic.

Jesus was Emmanuel Swedenborg: Contrary to popular belief, The Last Judgment, as foretold in the book of Revelation, occurred in the year 1757, and under the auspices of Emanuel Swedenborg, a gifted scientist, theologian—and, mystic. All of which has been thoroughly detailed in his work, The Apocalypse Revealed, a verse for verse account to the book of Revelation.

Therefore when the Bible speaks of Christ's second coming, it's actually referring to Emanuel Swedenborg and his work—as Swedenborg claims. And, while it may sound farfetched, it's all there. Much in the way Emanuel is another name for Jesus and means, "God with us" Matthew 1:23 with its familiar ring to John the Baptist: who wasn't really Elija (Elias), yet this was who he signified.

Jesus was a cool cat: Jesus Christ was a cool cat
I say the things that’ll make you think
so think about that
Break out your sandals and grow your hairs long
Live in a civilization where whores belong
... helping the poor get on
... healing the sores’ on
all those engrossed by that leprosy.
Your problem’s with all them that lack verity:
He wasn’t talkin’ about no heresy!

Opinions on Animal Rights

Princess — Sun, 03 Aug 2008 00:36:00 GMT

For once, I'm actually satisified with the quality of a video I published on youtube:

(Please visit the site to view this media)

As most people know, I've been a vegan and animal rights activist for 4 or 5 years now. I'm even a card-carrying member of PETA.

The video above is a little crude, and certainly not a comprehensive account of my own moral philosophy (if you've ever followed the debates I've participated in over the past couple of years, you'll notice the amount of material I've written on the topic could fill a Stephen King novel), but its at least a pre-emptive reply to people who believe that species is a moral characteristic or believe that evolution is a moral theory.

Coming Out Story - Before and After

Princess — Sun, 27 Jul 2008 14:40:00 GMT

(Please visit the site to view this media)

__doPostBack throws error 'object doesn't support this property or method'

Princess — Sat, 26 Jul 2008 19:06:00 GMT

When I was setting up Community Server on this site, I modified the site templates to include a PayPal donation button. After getting positioned where I wanted it, everything seemed to work fine and dandy. Today, I attempted signing out and back in to test some other changes, and Community Server started throwing a javascript error:

object doesn't support this property or method (line 39, char 9)

Which happened to correspond to the line of code highlighted in red:

<script type="text/javascript"> //<![CDATA[ var theForm = document.forms['aspnetForm']; if (!theForm) { theForm = document.aspnetForm; } function __doPostBack(eventTarget, eventArgument) { if (!theForm.onsubmit || (theForm.onsubmit() != false)) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); } } //]]> </script>

It was a strange error, because the code is autogenerated by ASP.Net. I thought my browser was screwed up, so I tried restarting it, testing the page in different browsers, looking for malformed HTML, but no luck.

I happened to have a copy of Community Server that actually worked. I diff'ed a page from my working copy against a page of my non-working Community Server and didn't notice the error at first, The only changes between the two pages was the addition of a URL and IMG tag for my donation button. I took a closer look at HTML and noticed the following:

<img src="https://www.paypal.com/en_US/i/btn/btn_donate_LG.gif" border="0" name="submit" alt="PayPal - The safer, easier way to pay online!">

The code I copy/pasted from PayPal include an item with a name attribute with the value "submit". The __doPostBack function calls the 'submit' method on the form... howver, there's an HTML element already on my form called submit. Javascript thinks the code is trying to do something with the IMG element, but it gets confused and throws a fit.

Solution to the error: remove the superfluous 'name' attribute from the IMG tag.