We've got it! AutoQuery (internal name Tigger) now has full support for XML datasources for its full gamut of ad-hoc queries and drill down.
This was a lot harder to implement than I expected. The first two approaches we took to selecting the data to perform ad-hoc queries against was too complicated. SQL is easy for this because the select will return only the columns you want, they are in order and sorted, distinct eliminates duplicates, and most important – it is returned in a flat structure.
XPath 1.0 on the other hand provides none of this. It's not flat, you get all nodes, you get duplicates, and sorting is limited. The third approach was so simple and straightforward that the rest of us were all kicking ourselves for not thinking of it when one of the developers proposed it. What we do is display the schema of the nodes returned by the XPath in a tree view with check boxes. The user then checks the boxes for the nodes they want used. We then flatten those selected nodes as the "columns" that a query condition can be run against in a filter.
And with all this we now have a full-blown B.I. tool that handles XML natively. No intermediate repositories. No limitations. No setup. And with this complete, we're going into the final beta.
In the workbook.xml file in an XLSX file, the recalc is partially driven by the build number. This is found in:
<fileVersion appName="xl" lastEdited="4" lowestEdited="4" rupBuild="9302"/>
The rupBuild number is the version the recalculation was performed under. As of today, the number for the versions of Excel is:
A "code war" is a competition between teams to see who can write the best code. We are having one today where everyone in development (it was voluntary but everyone signed up) is competing to see who can write the best code. They are give the problem at 9:00am (ie now) and have until 5:00pm to turn in their code (all times mountain time). I created the problem and am administering the contest.
The first issue I faced was what should the problem be. All of the initial problems I thought of would favor different groups here at Windward because it would match the expertise of that group. It's also critical to come up with a problem that does not have solutions all over the internet.
Well, after a couple of days I came up with it – writing an A.I. component for the board game Broadside. No one at work has any experience writing a computer A.I. so we have a level playing field. And this is a problem that cannot be brute-forced, working out even three turns for six teams to look at every combination will take too long. So it will require coming up with a clever way to determine what to do on each turn. I think this is more a contest of critical thinking than coding ability – and I like that.
I created a computer version of the game (yes horrible graphics but it gets the job done). It calls each player one at a time for their turn, and then the next player, and so on. So each team will write their code (I have a very poor AI implementation already for each to work from) and then all will give me their code and we'll run the game.
It took about 1/2 hour to go over the game with everyone and then another 1/2 hour as they got set up and hit me with a bunch of individual questions. I could tell from the reactions that it is definitely outside everyone's knowledge set. So I think it is a really good problem.
And it has never been quieter here - every door shut, every team totally focused on the problem with the world shut out. When productivity really matters, developers do know how to work :)
I came up with this idea because I played this game as a kid and had lots of fun doing so. It was a popular game so I figured the rules work well. But at the same time it's a very simple game so the logic of an A.I. player does not get wrapped up in complex maps, weird rules, etc.
We had pizza delivered and I've never seen people eat so fast. Lunch in under 5 minutes. Some of the teams grabbed their pizza and took it back to their offices - clearly still working through the problem in their mind as they grabbed the food.
One team said they have an awesome solution - but it apparently needs an infinite number of clock cycles. Two teams asked if they could have the weekend. And everyone is worried about what they can get done by 5:00. So I think it is a good problem for this kind of contest.
The program is downloadable below. It's broken up so that the player A.I. code does not have access to the internal structures. (The teams are on the honor system to not use reflection to hack the game.) So we have the game engine & UI project, the common API project, and a project for each player.
The art and rendering are atrocious. But for the purposes of the contest it is fine and doing this well would have added a lot of time and effort. I haven't touched DirectX in 15+ years so I would have had to learn it all over. And decent art would have cost a couple of hundred (I have zero artistic ability).
I also made one rookie mistake in the API. You can access the map either via a Point(X,Y) are as an array [Y][X]. Even with it being 15 years since I've written game code - this is horribly dumb. For anyone just starting in game programming keep it X,Y everywhere.
I also create a copy of all objects passed to a player on each turn so that they are getting a distinct object and it does not have any internal information. I think in a commercial game a better approach would be to keep the per player structures and update them. That would be a lot faster and have less memory fragmentation. But again, this works and I wrote this program in ~ 6 hours.
The A.I. I have in here is awful - it goes for any combat, even if it is one that the ship will lose. That gave me a fast way to test combat resolution and the end of the game logic.
The combat engine I think I did pretty good on. It walks each step of a ships move to determine if there is any combat and if so, assesses the results and sends the results as events to the players. Very straightforward and not that complex. I think it also does a good job of illustrating how to use LINQ to make code a lot simpler and more straightforward.
For the timer I used a Forms.Timer. It is not as accurate as alternatives and it has more overhead, but I am writing to the windows using Forms calls on each tick and so I need to be in the context of the UI thread. This is the most efficient way to get events in this situation. It also has a nice benefit that you do not have to handle re-entrancy. You may get another tick immediately upon returning from the event method - but you will not get an event in the middle of processing an event.
There is a tick for each sprite animation frame and then every N of those ticks, there is a move tick. The move tick will move a ship one map square (and assess any battery damage). If it is the final square, it assess ship fire and then the next move tick it gets the next player turn.
Calling the player code I wanted to make sure that a player taking too long to return or throwing a exception did not end the game. The exception part is easy, wrap each call in a try/catch. For the too long issue I make each call using an in-line Task object and then calling Task.Wait(1000). I really like how this works. Because it's in-line I can use local variables which keeps the code very simple. And if after a second they haven't provided a turn, the task is ended and I give them a random turn.
I don't know how useful this will be for others. I think the use of Task and LINQ is a good example. And the timer approach is exactly what you want if you are drawing to Forms objects. You are welcome to use the code in any way you wish.
Everyone had a really good time. Most of the company watched the final play (the free beer didn't hurt) and there was lots of cheering and commentary as the game played. And the shot clock was really important. Without that each team would have stayed in their base waiting for others to fight it out.
We'll continue to do this. It's an incredible morale boost. Highly recommended.
Full source code including player AI's at: Download Broadside
Blog by Tomas about his team's effort - Tomas' Perspective, or What the F*ck was the Yellow Guy Thinking?
The way we're all taught to profile is you install a profiler like dotTrace and then run your code under it. It shows you the hotspots and you dive in to that code to figure out how to optimize it. This is a great approach for many cases. I've used it myself a lot, especially back when I did game programming.
However, there are a lot of times where a much easier approach is equally effective. And for some cases, much more effective. It's fast, it's simple, and it gets the job done. What is it?
For a great many situations you will find that of the 10 times you broke into the program, it is in the same code each time. You now know where the code is spending its time. And you did this without installing a profiler, without running it, without having to dive into its results.
This approach is not a panacea. First off, a profiler will give you the actual lines of code that are taking the time, and how much on each line. This quick approach works great when it is a single line of code. The more spread out the issue is, the less helpful it is. Even if the time is all in one method, it can be certain parts of a loop for example that are sucking up the time – but it is various parts each taking significant time. There are many other cases where this is not the best approach.
But there are also some great advantages to this approach. With our reporting/docgen program a lot of the time the big hit is a single select in the report template. A profiler will show that it is the selects that are taking the time. But breaking into the debugger makes it easy to see what select on each break. If it is consistently the same 1 or 2 selects, then you know that what needs to be optimized is not executing a select, but a specific select. (Or a column in the database needs to be indexed.)
Another case we have seen at times is the hit is importing images or sub-reports from a specific server. Again, if on each break it is waiting for a file to be read from a website, and the break always shows that it is when hitting a specific website, then the problem clearly is not reading a file, but the response time of a specific server.
With very rare exceptions I always use the debugger break approach first. When that is sufficient (about 60% of the time), then I am working on the performance issue a minute or two after starting.
We have a NavBarGroup in our (super awesome) SQL wizard that is a list of all columns in the select. We needed a checkbox in the header to set if the select should be distinct. After a bit of work and some help for the DevExpress support team, we have a really nice solution.
NavBarGroupChecked inherits from NavBarGroup and can just be dropped in to replace it. It adds a RepositoryItemCheckEdit member that tracks the checkbox and implements custom draw. It has a Checked property that tells you if it is checked and an event that will be called when the Checked status changes. That's pretty much it. Just drops in and works.
Word 2007 & 2010 make it trivial to write blog posts from Word – if you follow some key guidelines.
First, create a "Blog Post" new document, not a "Blank Document. This puts Word in a special mode where it can (not will, can) create very clean html. And remember, saving what you write to disk is totally distinct from publishing it to a blog.
Second, always paste in bitmaps using "Paste Special", "Device Independent Bitmaps." With any other setting the quality of your picture will be poor, and in many cases will not be displayed at all.
Third, never position any bitmap except for inline, top left, top center, or top right. If you do any other setting for a picture it will not place right in the blog:
Fourth, the only paragraph settings to use are Normal, Quote, and the Heading ones. Your blog knows those, it doesn't know the others.
Fifth, do not create positioned tables. Left, Center, & Right are fine. But do not set Indent from left, do not set text wrapping to around. The "positioning…" button should be disabled. The html Word creates for any positioned object generally looks very wrong in a blog.
Sixth, do not use text boxes, shapes (the Word drawing objects), fields, content controls, or any other advanced object.
If you follow the above rules when you publish to your blog it should appear very close to how you wrote it.