Best and Worst States for Freedom


I saw the new study of the freedom index from George Mason Unversity’s Mercatus Center. The study ranks freedom based on three factors

  1. Fiscal Policy (35.3%)
  2. Regulatory Policy (32%)
  3. Personal Freedom (32.7%)

Based on this study, top 10 states in terms of personal freedom are:

  1. North Dakota
  2. South Dakota
  3. Tennessee
  4. Pennsylvania (tied for 3)
  5. New Hampshire
  6. Oklahoma
  7. Idaho
  8. Missouri
  9. Virginia
  10. Georgia
  11. Utah

The bottom 10 states are

  1. New York
  2. California
  3. New Jersey
  4. Hawaii
  5. Rhode Island
  6. Illinois
  7. Maryland
  8. Vermont
  9. West Virginia
  10. Mississippi

I took the numbers and looked at the list from other view points. The states with the least individual state and local tax burden. Freedom rank in parenthesis:

  1. South Dakota (2)
  2. Oklahoma (5)
  3. North Dakota (1)
  4. Tennessee (3 – tied)
  5. Alabama (18)
  6. Montana (12)
  7. New Hampshire (4)
  8. Idaho (6)
  9. Texas (14)
  10. New Mexico (21)

And the highest state/local tax burden

  1. New York (50)
  2. Hawaii (47)
  3. New Jersey (48)
  4. Maine (39)
  5. Vermont (43)
  6. California (49)
  7. Wyoming (36)
  8. Wisconsin (38)
  9. Rhode Island (46)
  10. Connecticut (40)

I started looking at the numbers and saw the figures for income. While that might be an interesting number to post, it does not tell who is best off financially, as many high income states are also high taxation and/or high cost of living states. To determine the best state to live in financially, I took total income minus tax burden and compare to the cost of living. Doing a simple calculation, I find these states to be the best, financially, to live in.

  1. Virginia (8)
  2. North Dakota (1)
  3. Wyoming (36)
  4. Illinois (45)
  5. Nebraska (22)
  6. South Dakota (2)
  7. Massachusetts (30)
  8. Colorado (19)
  9. Kansas (26)
  10. Washington (29)

And these are the 10 Worst states to live in financially

  1. Hawaii (47)
  2. Alaska (13)
  3. Maine (39)
  4. Vermont (43)
  5. California (49)
  6. Rhode Island (46)
  7. Mississippi (41)
  8. Arizona (11)
  9. Oregon (28)

I did this again by taking the cost of living and figuring out the income necessary to live in the state and ended up with a nearly identical list. On the top list, North Dakota and Wyoming changed places, South Dakota dropped to 12th place and Washington to 11th and Minnesota and Connecticut made the list. On the bottom Mississippi and Arizona changed places.

From the figures, the states with the lowest tax burdens are generally the states with the most freedoms. I don’t know whether a case could be made that more taxation brings on more legislation to reduce freedom or not (the data is inconclusive), but it makes sense: when government taxes more, it has to find ways to spend the money, and at least some of that will be in the form of regulation (which also brings in more money to the state).

But this does not mean you are always the best off financially in the states with the most freedom, although the states with the worst freedom ranking are represented fairly heavily in the 10 worst states to live in financially, so there appears to be more of a correlation to a lack of freedom and financial woes.

Peace and Grace,
Greg

Twitter: @gbworld

Advertisements

Sharing Sessions in ASP.NET


In an internal work mailing list, I had a question on sharing session across multiple applications, which I assume to be web applications. It can be done … sort of. Here is the question:

The user starts an application via a browser. At that time we have session information. Now the user clicks a link within that browser that opens another application in a new browser. I want to pass the session state between the two applications.

Before getting into this, you should understand how the web works, which I detailed in a post in 2005 (which gets somewhat deep, but not all the way down to the HTTP handshake). Now for a bit of how ASP.NET works. If this goes over your head, refer to the link above.

When a request is made for a page, EVERYTHING is sent to the server. Well, not completely true during the handshake portion, but once the browser determines it has reached the correct server, it sends over the page request information, including any querystring and form arguments, and sends the cookie(s) associated with the request. There are two types of cookies sent: server cookies and user cookies (at least I think we call old style cookies user cookies).

One thing that is passed is the session token, which is how the server gets to the session object to get data for a session.

To have a second application access the session information, you have to do a couple of things. First, it has to belong to the same domain. It is not considered kosher to have www.mydomain.com/myapp1 talk to www.mydomain2.com/myapp1 talk to each other, due to cross site issues, but it is possible to have www.mydomain.com/myapp1 talk to www.mydomain.com/myapp2.

To set up the two apps, in the same domain, so you can get some session information, you have to use the same encryption keys for the server cookie. This is done by setting up the machine keys specifically in the configuration file (web.config). This is what the machine key section looks like (as a template).

<machineKey validationKey="AutoGenerate|value[,IsolateApps]" decryptionKey="AutoGenerate|value[,IsolateApps]" validation="SHA1|MD5|3DES"/>

You cannot use AutoGenerate, as each application will generate a different key. Instead, you have to create a key. So, how do you do this? The easiest way is to search Google for a machineKey generator, like the one found here: http://aspnetresources.com/tools/machineKey. It creates something like this:

<machineKey validationKey="D08D3A0822675C3B62CB539282FFD2BA596B5442D9A8CD225FCF9A9384F7680A338355EF0BB0D9A9698ECEB905508B50548670A055813EBBC391273A16154526" decryptionKey="4653D55CBBBF9D85CAFC0705D734946F007121B7A8A3EF431CDF43805F47374B" validation="SHA1" decryption="AES" />

You then use this section in all apps that need to share information. (I hope I have not forgot a step here, so I will amend this if I find I have).

The problem here is you can easily grab the session key, but not the actual session information. Why is this? Well, the session key comes from the cookie and is decrypted, but the actual session information is held not only by key, but by application. Since MyApp2 is not MyApp1, you cannot easily grab it. So, how do you solve this.

The easiest method is to store session information that might need to pass in some form of data store. In the past, when I needed this type of “single sign on”, I put it in SQL Server. You simply try to get information from session and call SQL Server (and place into session) if not found. The item(s) will not be found when you initially switch applications, so the first hit on a new application will cause a hit to SQL Server.

But the email I got this morning stated:

I have got it working using the SQL server with this solution http://www.sneal.net/blog/2007/06/27/SharingSessionBetweenWebAppsViaConfiguration.aspx , but as mentioned SQL server is not a viable solution.

Okay, so think outside the box. If you can’t use a database, what else can you use? The answer is “any other type of data store”. So, where can we store data. Here are some possibilities:

  1. A file. The issue here is the file has to be accessible from more than one web application, so you either have to map the same folder for both applications or lessen security slightly in IIS. The first is a configuration complexity, while the second is a potential security risk. The solution requirements will dictate if one or both of these are not workable.
  2. Set up a web service and let it store the session information. A bit heavier, but it has the benefit of even working cross domain as long as you can figure out a way of passing session information (which is a completely different problem).
  3. Use a distributed cache solution for session state and hook in various applications.

Let’s suppose the web service is used. Here is the flow:

  1. User logs into application 1
  2. Session is created in the application and the session information that needs to be shared is sent to the web service and stored there
  3. User does more work in application 1
  4. Any new information added to session is also added to the session web service
  5. User goes to application 2 (with some means of passing the session key)
  6. Application 2 checks session and finds nothing
  7. Application 2 calls the web service with the session key
  8. Information pulled from web service placed in session in Application 2
  9. User is able to work

There are other ways of solving this problem, of course, but the mechanism is similar with each solution. For example, Alichisoft has a product called nCache (distributed cache) which could be used as this store. I believe they also have libraries to more easily facilitate this type of scenario.

Hope this helps.

Peace and Grace,
Greg

Twitter: @gbworld

How Many Squares


I have seen a lot of these going around on FaceBook.

It surprises me so many people cannot get the right answer, or often even get close. Here is how I break these down.

First start with the smallest squares. These are formed by the overlapping squares and we will call them 1 unit squares. There are 8 squares that are 1 unit by 1 unit (1 x 1 squares) or 4 each in 2 clusters. So our formula, looking at the square below is

  • (4 x 2) ==
  • 8

1by1

Next we got to 2 x 2. There are 4 squares and 4 rows, but we also have to take in account the 2 that overlap. So we have (4 x 4) + 2 = 18. Add in the original formula and we have

  • (4×2) + ((4×4) + 2) ==
  • 8 + (16 + 2) ==
  • 8 + 18 =
  • 26
  • So we now have 26 squares, as shown below.

2x2

There are no 3×3 squares

3x3

So the next size to look at is 4 x 4. To dissect this, you have to consider there are overlaps. This is what most people see, at first:

4x4_1

But there is an extra row:

4x4_2

And an extra column:

4x4_3

So the answer for the 4 x 4 squares is 3 overlapping rows by 3 overlapping columns (3 x3 = 9). So our answer now breaks down as

  • (4×2) + ((4×4) + 2) + (3×3) ==
  • 8 + (16 + 2) + 9 ==
  • 8 + 18 + 9
  • 35

There are no 5×5 squares

5x5

So we have to consider the 6 x 6 squares (those comprise of 3 of the 2 unit squares).

6x6

There is an overlap here, due to the size of the square:

6x6_2

So there are 2 squares on each row and 2 rows (see above and below):

6x6_3

This means there are 4 squares (2×2). The formula is now

  • (4×2) + ((4×4) + 2) + (3×3) + (2×2) ==
  • 8 + (16 + 2) + 9 + 4 ==
  • 8 + 18 + 9 + 4 ==
  • 39

If you go to the next size (4×4), there is only one.

8x8

  • (4×2) + ((4×4) + 2) + (3×3) + (2×2) + 1 ==
  • 8 + (16 + 2) + 9 + 4 + 1 ==
  • 8 + 18 + 9 + 4 + 1 ==
  • 40

So the answer is 40.

Peace and Grace,
Greg

Twitter: @gbworld