Say you want to connect to a remote machine with Remote Desktop (RDP) but want to get hold of the actual machine's console. That is - you want to get the session that you would have were you standing in front of the machine physically.
To do so, run the following command:
mstsc /consoleThen connect to the machine as you would with a regular RDP session. What you will get is the actual console session.
Thanks to Chen Avnery for this little (but helpful) info.1. Why can't there be UDA's in T-SQL? Granted, it's easy to write it in CLR, but sometimes it would be simpler (and more appropriate) to write it in SQL. It also took me a while to figure out that indeed there is such limitation...
2. UDA's must be serializable. Why? I don't know yet (still need to figure that one out), although I have some ideas, but anyway it's besides the point - it's a must and I assume there are good reasons for that. The problem is that whenever you're doing something slightly more complicated than just an average or Product, you need to accumulate all the values until you get to Terminate() (e.g. a variation on STDEV). This means that this list you've just accumulated could grow significantly. Now to the pitfall - when you use user-defined serialization (which you would have to in this case), you must specific the maximum size that the UDA structure could grow to. This maximum size is limited to 8000 bytes (*sounds familiar...). So in my case, I'm using a UDA over double values, and thus I'm limited to aggregating a little below 1000 records. IMHO this reduces the practical usage of UDA's to about 50%...
3. I tried to write a UDA for decimal data. No matter what I did, it constantly produced a function defined to return decimal(18,0). In other words - no decimal numbers to the right of the dot. In the end I didn't have the time to find out the KB article talking about it, but I suppose there is - I pretty much tried everything. In my particular case using double values was an acceptable compromise - it won't always be that way...If you're interested in working with or learning about Machine Learning, you really MUST check out WEKA. When I first saw WEKA, a few years ago, it looked like a cute tool to start learning ML, with a very small set of implemented algorithms and only available for Java developers. Now, it has become a very rich research platform, in which one can easily test a very wide variety of ML algorithms with endless tuning parameters and analysis tools. You can read data directly from a database and you can now even run WEKA directly from within your .NET code (check also this) !!!!!
I'm a complete newbie with WEKA, but it seems that it's going to be a lot of fun and much faster working with it than anything I did before. I just hope it will hold up to the expectations that are building up in me now...
One more thing - notice that there is the "book version" and the "developer version". The former is the one on which their book is based on and is not expanded (only bug fixes). The latter is the version that is on constant development, has more features, and significantly more implemented algorithms.
When opening WLW it says that the Beta has expired and forwards me to download the new version. When I do that - I get a message that it is not supported for 64-bit windows (I'm using XP 64bit).
Hum, what?
1. 64bit is alive and kicking and getting more and more users. It's time that software companies (MS being one, IMHO) get used to provide support for 64bit platforms by default.
2. If the new version does not support my platform - why sending me to download it and waste my time and nerves?
Grrrrr...Yesterday I got once again a Chain Letter. In case you don't know - I HATE CHAIN LETTERS!!!
This time, it was a pseudo virus alert. When I complained with the sender, urging her to stop sending me chain letters, she said: "But it's a VIRUS alert! I can't take the chance you'll miss it!"
What people don't understand, is that if 50% of the users would think like this sender, there would be no Internet. Nada, zip, nil, rien du tout, nothing, niets, kadachat...
Just do the math:
Let's assume 50% of the people believe in those nonsense and send such a virus alert to 20 other people.
Now assume it takes on average 5 minutes from the moment you get the email until you forward it (some a little more, some a little less).
In this worst case scenario, we flood the Net with 10^12 emails after 1 hour. Keeping the 5-minute window I assumed above, it's more than 3 BILLION emails per second. No need to calculate how many emails would be sent after 2 hours - there would be no Internet by then.
Fortunately for the Internet, most users know better than to forward Chain Letters...My curiosity has been arisen big time. Apparently, there is a new kind of malware, which involves the use of natural language dialogue to extract information from users, in the disguise of a flirtatious conversation. It's called CyberLover and was apparently developed in Russia. According to PC Tools, this program can converse with a human for 30 minutes without the dude being able to see he's talking to a robot.
The Turing Test has officially been passed...
Read the original warning issued by PC Tools, or an article at ComputerWorld.
AMAZING!!!
A long time ago I used to use BugTrapper - an application that sits on the production server, records every instruction, and makes it possible to "play" everything back, step by step. It's a great tool to analyze bugs and especially crashes "post mortem", as long as it's not related to some obscure race condition (the overhead of using BugTrapper often ruling out the race in the first place).
I think there definitely is a case for applications like this, and the fact that Mutek hasn't been able to push itself farther into developers' awareness is quite surprising to me.
The feature I would like to see in an IDE is a mini-BugTrapper. I would like the IDE to be able to record up to a certain amount of instructions (say up to 100,000) during debugging. How many times did you stop at some breakpoint and suddenly realized you should have put this breakpoint a little bit earlier in the flow? You really need to see the value of some parameter, or the actually executed flow, a few steps back - but you can't. The only thing the IDE gives you is the static current call stack - which just isn't enough. You want to know what variables caused you to get into that current call stack, but that's beyond the scope of the IDE's features.
That's, IMHO, a killing feature that could significantly boost debugging time.The other day I decided to use a "goto" statement in my C# code. It was a difficult decision to take, and was primarily motivated by the need for readability.
Apparently, Linus Torvalds also thinks there are cases where "goto" is appropriate, so I'm in good company...
Thanks to Scott Hanselman for pointing to this thread.Let me quote from MSDN about System.Double:
"A mathematical or comparison operation that uses a floating-point number might not yield the same result if a decimal number is used because the floating-point number might not exactly approximate the decimal number."I found this funny, go figure...
I recently got back to reading Jeff Atwood's blog, after a long pause on my part. I was very surprised to see advertisements there, especially since I remembered him discussing this issue in the past - opting for the negative. Of course, one can always change his mind. But still, I find it quite funny. Reading the last few comments on that post you can read him agreeing that advertising on a blog is "like advertising on your business card".
Apparently he now doesn't mind advertising on his business card ...By the way - I found Jon Galloway's comment hilarious...
Yet another MSDN and .NET WTF:
I'm currently implementing some temporary code that was written in VB into our C# infrastructure (let's skip the details). Anyway, there are parts in the VB code that I would like to group because either they are currently not being used, or for some reason I want to hide it from view and get to it at some later phase.
Obviously, a #Region directive seems like the best solution.
My VB is quite rusted, but using common sense I tried using the same syntax I'm used in C#. But alas - it didn't work. So I searched MSDN - hey, it should work! Well, VB have this little difference that the identifier_string MUST exist and it must be surrounded by quotation marks. OK, no biggy, I usually put it there anyway.
But why doesn't it work?
Well, there is this tiny little limitation, hidden from you if you rely solely on MSDN, that "'#Region' and '#End Region' statements are not valid within method bodies."
Which raises two questions:
1. Why, in Heaven's name, should there be such a difference between C# and VB. It's just a freaking compilation directive!
2. Assuming there is some justified reason for that (which I doubt - I guess it's just a non-implemented feature) - would it hurt someone to put this info in MSDN so I won't have to get crazy trying to figure out why it doesn't work?!?!
And now to a personal to-remember note:
I relied solely on Intellisense and Resharper to know the code is wrong. I'm using the C# only version of Resharper, so I have no idea whether Resharper would have been more helpful. Anyway - had I compiled from the beginning (or at least looked at the message Intellisense gave me) - I would have seen much sooner why it doesn't work...Shai Agassi is a person who doesn't have to prove himself - he's done it 400,000,000 ($) times and much more. I had the chance of working for him at TopTier, though at the time he was mostly in the US and I don't think he'll remember me.
He's now investing all his power in the Project Better Place, with the goal of transforming our fuel-based cars into electric-cars, by providing the necessary infrastructure and business plan.
Will he succeed? I sincerely hope so. I am also willing to be one of his first customers for a pilot plan in Israel. If anyone is to succeed in such a project - it's him.
Some say his real goal is to own the software that will handle the whole system. Well, I think that if he succeeds in this project, it makes complete sense and there's no harm about it. If making this world a Better Place means Agassi will own the most important software in history - so be it!In any case, I admire him for being ready to risk his most valuable asset - his reputation - for this huge and very risky project.
If you want to keep track of what's going on, I suggest you read his blog.
Good luck Shai!By Henry Kissinger:
Source: Wikipedia
D., my colleague came to me today asking for help with printing problems. At some point I decided to log off, but then I couldn't log on again. The machine kept saying that the current time is different than the network time. I couldn't log on with any of our domain users (including Administrator), so I had to log on with the local Admin user. Looking at the time, it looked fine. After digging and searching for 15 minutes, we discovered that the date differed - running some simulation D. had to move his clock one day ahead and forgot to move it back.
Once we moved the clock back to the right day, he could print flawlessly!Things gives rise to many questions:
1. Why couldn't he print when his day was wrong? I understand there are synchronization issues involved - but in 2007 (almost 2008) these things shouldn't happen! Sometimes you really can not have all your computers synchronized. That's life!
2. Why did the error talk about time and not date?
3. Why couldn't we even log on with a domain user?
Grrrrrrrrrrrr........!@#!@#!@#@!@#!@#!@#Just a small tip:
Say you want to run a query that returns the first @X results of some query, such that @X is a parameter.
The simple "SELECT TOP @X ..." statement doesn't work. I found this weird, because I know for a fact that SQL 2005 supports using a parameter in the TOP clause (as opposed to SQL 2000 where you had to use either dynamic queries or the SET ROWCOUNT statement).
Solution - surround the parameter with parenthesis as so:
"SELECT TOP (@X) ..."
Something to remember...
For the past few years I've been working for a global investment firm. At the beginning I worked part-time as a freelancer, but recently the company opened an R&D facility in Herzliya and now I'm a full time employee again. We're now looking for exceptionally talented quantitative analysts, to participate in the development, validation & documentation of risk & analytical applications and processes.
Our firm has been engaged for over 10 years in the research and development of systematic trading models for the global financial markets. The developed models are used in the actual money management of clients' portfolios.
Role will involve working on new risk management models, data extrapolation, and trading model analysis and development.
Requirements:
· MS or PhD in Math or Physics
· Exposure to stochastic calculus
· Excellent general modeling skills
· Grasp of PDE’s and Monte Carlo
· Experience in statistical data analysis or signal processing is a plus
· Experience in Matlab \ C# is a plus
· Financial knowledge is a plus
To apply, fax your resume and a cover letter to 09-970-7329 or email careers@eaglets.com
I recently had to extensively use a feature in SQL I seldom used before - inserting the results of an EXEC statement directly into a table. Sounds a reasonable thing to do, right? Accidentally, I had a bunch of stored procedures calling each other, using temporary tables, and finally filling a "final" table. I finished writing the whole thing, and then - BABOOM! - it doesn't work, because "An INSERT EXEC statement cannot be nested". Huh? What?
Why? Why didn't you say so before?
Following is a quote from SQL Server Books Online for "INSERT (Transact-SQL)" :
Is any valid EXECUTE statement that returns data with SELECT or READTEXT statements. The SELECT statement cannot contain a CTE.
If execute_statement is used with INSERT, each result set must be compatible with the columns in the table or in column_list.
execute_statement can be used to execute stored procedures on the same server or a remote server. The procedure in the remote server is executed, and the result sets are returned to the local server and loaded into the table in the local server.
If execute_statement returns data with the READTEXT statement, each READTEXT statement can return a maximum of 1 MB (1024 KB) of data. execute_statement can also be used with extended procedures. execute_statement inserts the data returned by the main thread of the extended procedure; however, output from threads other than the main thread are not inserted.
Did you see any clear mention of this limitation???
I've come to really like table variables in SQL. They are a nice and natural development of database programming. And, when used smartly, can greatly improve performance compared to using temporary tables.
Today I've discovered that table variables cannot be truncated. I had no idea...
Anyway, I've found a cool source of more information about table variables, including some stuff that is not or not well documented in Books Online. Check here and here.
When you think of it - it makes sense. As far as I know, table variables are memory constructs whereas temporary tables are kept in tempdb. Truncating a table simply removes the reference of the table's page from the database. However, if the table is only kept in memory and in no actual database - it has no meaning...
I took the typing test everyone talks about, here are the results:
Number of words typed: 144
Test duration: 3 min
Speed: 48.1 words/min. (240 keystrokes/min.)
Error penalty: 4
Accuracy: 97.2%
It's good, but I've got a lot to improve. I must say it made me quite nervous - causing me to make several time-consuming errors (didn't get high accuracy for nothing). Also for me, writing code goes way faster (even before counting Intellisense, Resharper and the like in) than text I've never seen before. There are some words, or parts of words that I can just type at lightning speed (new, class, for, if, the, select, from, ...)
