So I found a programming blog where the writer indicated he needed to convert DateTime to ticks and vice versa. (This is in C#.)
He presents this:
public static long ConvertDateTimeToTicks( DateTime dtInput)
long ticks = 0;
public static DateTime ConvertTicksToDateTime( long lticks)
DateTime dtresult = new DateTime(lticks);
Why write a separate function for these as an example? It’s right there in .NET (unless he was supposed to wrap the functionality, and copypasta’d for convenience).
In Western chess, we have accepted that computers outplay humans, full stop. (Some might say we’ve resigned themselves to this fact. Please hold your applause; I’ll be here all week!)
Shogi (Japanese chess) is quite a different beast. Western chess revolves heavily around material balance. If you’re down a Pawn, you’re expected to have a significant advantage in time or position. Being down a Knight, or even two Pawns is hopeless in a typical position. In Shogi, material is not as pressing. In fact, unlike chess, if you’re down in material, you probably want to exchange pieces.
That’s because of the coolest feature of Shogi…piece drops. In Western chess, a captured piece is out for good. In Shogi, when you capture a piece, it can be returned to the board under your control, with few limits. There are many more opportunities for positional exchanges of pieces.
With regards to the computer, dropping pieces greatly expands the number of possible moves, reducing the effectiveness of brute force searches. The board is always full, so there is no “endgame” with just few pieces. In Western chess, computers can use endgame tablebases to play positions with few remaining pieces perfectly…if they even have to play that far.
A couple months ago, I complained about someone who wanted to store dates in database as strings.
For you non-programmers, it’s like if you do the following: Take your paycheck, but don’t go to the bank to deposit it. Instead, go to a currency exchange center and cash it out — in yen. Now go to your bank and deposit the money.
Argggggh. There are reasons why parameterized queries exist. Use them. This is a public website where people need to input data. And don’t ask me if you can store dates as strings in the database. That’s insane, and there will be lots and lots of heartache later. Thank you for listening to this rant, even though most of you have no clue what this means.
(Yes, my level of annoyance has caused me to post this both here and Facebook. Unfortunately, it’s too long for Twitter.)
Unless you don’t watch any TV whatsoever, you’ve undoubtedly seen those Mac vs PC commercials. I like them; they tend to be funny:
With the recent release of Windows 7, Mac has launched a counter-campaign, reminding people Microsoft that they keep promising to fix whatever was wrong with their last OS–and failing:
Microsoft’s OS problem
Certainly Windows ME was horrible, and Vista suffered from dreadful launch (although if you waited until Service Pack 1, it was fine). But XP was a good product, and this is Microsoft’s biggest problem. XP works so well for most people, there’s not much motivation to upgrade.
Apple’s commercial problem
Understandably, Apple can’t say in their commercials Windows XP was good, but the most recent attack feels a bit unfair. But there’s a bigger problem with the Mac vs PC campaign:
The PC guy is funny and interesting. The Mac guy is not.
Mac stands there, supposedly hip and cool. Occasionally he has a snappy one-liner. But you know PC is going to be driving the entertainment…you laugh with (or at) PC…subconsciously, good times and feelings are being associated with PC. Mac feels too aloof and arrogant.
If you used to, still do, or think you will use it, the article The Curse and Blessings of Dynamic SQL seems to be an excellent write-up on some important aspects. Including defending against dreaded SQL injection attacks.
On help forums where someone responds “Use Dynamic SQL!”, there’s a good chance there will an example like the following:
DECLARE @SQL nvarchar(2000)
SET @SQL = 'SELECT * FROM TableName WHERE Server = ''' + @ServerID + ''''
However, simply using EXEC is not a very good practice. Instead sp_executesql can be used to allow a more secure parameterized query:
DECLARE @SQL nvarchar(2000)
SET @SQL = 'SELECT * FROM TableName WHERE Server = @ServerID'
EXEC sp_executesql @sql, N'@ServerID nvarchar(100)', @TableName
For some reason, the syntax created a mental image of a du-rag clad Darius N’ServerID rapping about the virtues of Dynamic SQL.