I haven’t seen this reported anywhere else, so I might as well throw a post up about it.
Valve recently launched their Steam Wallet feature, which was widely reported, but I just found a way to add custom amounts to your Steam Wallet (so you won’t be stuck with leftover pennies).
If you’re logged in and access the Steam Wallet page, you can add specific increments. If you look into what the actual buttons are doing, they’re all just using a javascript call to add those amounts, like “javascript:submitAddFunds( 1000 );”. As this gives you the necessary precision to add whatever amount of money needed, this will help to make sure you don’t have anything extra sitting around. Valve is still validating the amount to make sure it’s over $5.00, but it appears to work fine for any larger amounts.
So basically, go to the Steam Wallet page and throw “javascript:submitAddFunds( 1337 );” into your javascript console or address bar to try this for yourself.
Based on this interview, this looks like something they intended rather than an exploit, so I feel comfortable using it:
]]>As gamers who’ve used these kinds of systems before, we wanted to avoid some things we didn’t like. One was being forced to add more funds than we wanted (and seeing purchase prices that didn’t seem to match the funding options) and the other was being forced to do conversion into some virtual currency in our heads.
We’re not doing either of these in the Steam Wallet.
SELECT CAST(NULL AS varchar(1)) AS [C1], CAST(NULL AS uniqueidentifier) AS [C2], CAST(NULL AS uniqueidentifier) AS [C3], CAST(NULL AS int) AS [C4], CAST(NULL AS varchar(1)) AS [C5], CAST(NULL AS varchar(1)) AS [C6], CAST(NULL AS varchar(1)) AS [C7], CAST(NULL AS varchar(1)) AS [C8], CAST(NULL AS bit) AS [C9], CAST(NULL AS varchar(1)) AS [C10], CAST(NULL AS varchar(1)) AS [C11], CAST(NULL AS varchar(1)) AS [C12], CAST(NULL AS varchar(1)) AS [C13], CAST(NULL AS varchar(1)) AS [C14], CAST(NULL AS varchar(1)) AS [C15], CAST(NULL AS varchar(1)) AS [C16], CAST(NULL AS varchar(1)) AS [C17] FROM (SELECT 1 AS X) AS [SingleRowTable1] WHERE 1 = 0
(Note, this query has not been modified in any way, this is exactly as I found it)
When I investigated this, I found the following code generated this awesome SQL:
GetContext().CreateObjectSet<ProductFamily>().Where(pf => ids.Contains(pf.Id))
If you’re unfamiliar with Entity Framework, this query should pull any ProductFamily records whose Id is within the ids collection. The problem I experienced came up when the ids collection was an empty set. I would have expected EF to short-circuit this query so it didn’t even hit the database, but this is another case where having a good profiler is often a necessity when using an ORM.
I just came across another query that generated similar SQL:
public virtual T GetById(object id) { return Items.SingleOrDefault(i => i.Id == id); }
This is on our base repository along with numerous other methods for ease of reuse, which is why an object comes in – we can support Guids, ints, or whatever other PKs are in use. This new issue came up when we were using a nullable Guid elsewhere. We weren’t checking to make sure it had a value, and instead passed the nullable Guid in directly. Once again, EF detected that the value was null and that no records will match it, but decided to execute a query anyway.
]]>
First of all, a picture of the keyboard (Logitech G15) I’m replacing:
Here’s the new keyboard (Sidewinder X6):
Some general thoughts so far:
Overall, I’m a big fan of the X6 so far and I’ll definitely get used to the differences. The main thing I’ll miss is the LCD, though I suppose Ventrilo was one of the few apps I used it for. I’ll definitely keep using the X6 as my primary keyboard as I do prefer the feel of the keyboard over the G15 – Thanks again @WindowsGamer!
]]>
This cropped up when I decided to introduce logging into my application using the Microsoft Enterprise Library. I soon found out that the current version of the Enterprise Library will not work with .NET 4.0 Beta 1 due to an existing bug.
The quick fix to this is to make sure your project is targeting .NET 3.5 SP1, which my project already was. After some more digging around I realized that though I was targeting 3.5, Visual Studio was hosting my WCF service using its .NET 4.0 version of WcfSvcHost.exe.
The workaround that I’ve created involves pointing my project to the VS 2008 version of the WCF Service Host for debugging purposes:
The external program path I’m using is “C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\WcfSvcHost.exe”, though your path may vary. I set the working directory to my project’s debug directory.
Here is the direct link to the Microsoft Connect bug report in case you want to validate it or vote it up.
]]>When I find the time I’ll try to upload a few projects I’ve worked on over the past few years.
]]>