Wednesday, October 22, 2008

Inside the application data directory

If you have ever looked in the Toad data directory you were probably a little bit bewildered about all the stuff in there. This article will try to shed some light on what all the files in there are used for by the Toad application.

First off all before we start off here, lets begin with something really basic. If you don't know where the application data directory is there is a very easy way to find it. Just go into the Help|About of Toad and click on the Application Data Directory link.

This will bring up a windows explorer window showing the data directory. Just one note, if you want to tinker with something in here be sure to shut down Toad first.

So now you see the stuff in the directory. Lets start going through the files to see what they are all used for.

Action.logThis file tracks your usage within Toad. If you agree to share this with us (And please do, it really does help us) it's contents will be sent automatically to us periodically. We collect the data regardless though and it will be included in a support bundle.
Connections.xmlThis file contains all the contents of your connection manager (Or new connection dialog if that is your fancy).
ConnectionTrace.logCreated to contain the SQL Output connection trace log file when you log to file.
ExceptionTrace.logThis file contains a log of all exceptions that have been encountered while running the application. This file helps us a lot when you generate a support bundle.
Settings.xml Global settings configuration file. This file contains a lot of application settings save in a SOAP formatted XML file.
SqlServerPlanPrefs.xml File used to generate SQL Server execution plans. The last support bundle you have generated.

There can be some more log files generated too by setting different command line option to generate additional debug information. All these files will then be included in the support bundle when generated.

Now lets look at what is in all the sub directories and what they contain.

Automation This is a temporary directory used by automation when running automation scripts.
Cache This directory is used to spool cache database meta data out to disc if this is enabled. The data in here is in binary format and can always be recreated by fetching it from the database.
CNSScripter This is a temporary directory used by compare and sync, some script generation for alter dialogs and the script tab in the Object Explorer.
Context This directory contains settings that depend on the context within Toad. Depending on the sub folder name it contains different information. First have database browser filters, and their named equivalent in two different folders ("Filter" and "NamedFilter" respectively). We also have the RHS layout of each type in the "Type" directory. Finally you have custom data editing statements in the "Adapter" directory.
Keyboard Contains keyboard layout customizations if you have done any.
Layout Contains different layouts of parts of the application. Examples of these are the tool tip panes of the editor and column layouts of the messages tool window.
ModuleSettings This is another directory where we have a lot of settings saved. They are saved in the same format as the Settings.xml file. The files here are divided by functionality.
Plugins Directory that can be used by different plugins of Toad for whatever they choose.
Session Files in this directory store desktop configurations. That means they contain toolbar customizations, tool window locations by default but can contain more or less information.
SQLRecall Data files for SQLRecall.
Templates This directory has different templates used in different parts of the application. This includes code snippets, some connection startup scripts and DOE templates (Only supported by Toad for DB2 currently).

If you are running into problems which you suspect might be settings related the easiest way to check that out is to just rename the settings directory (You need to close Toad first) and then restart Toad. If this solves the problem the two files that you can almost always copy over from your old directory without any problems is the connections.xml, sessions.tss file and the Layout directory. Replacing these files you can reset all your options "the hard way" without loosing your connection history and the layout of all tool windows which are usually the part that takes the most work to restore in my opinion.

Tuesday, October 21, 2008

Code completion revealed

From the first version of Toad we have always had some form of code completion (It was originally called Toad insight or something like that) but it has always been a fairly simple affair where you either got a list of columns in select statements or a long list of objects of many different types completely unaffected by the context in which you invoke the code completion.

Starting in 4.0 the code completion support was completely rewritten to be very context aware. Now Toad should know that if you are writing a select statement and are between SELECT and FROM you probably want a list of columns and if you write JOIN you probably want to join on a foreign key from tables already specified etc. There has been little bit of a backlash on this and I have to admit that this code did have some bugs and when that happened you usually didn't end up with any code completion at all which is worse than what we had in 3.x. Hopefully for the soon to be released 4.1 release most of these should have been fixed and you will really see the benefits of the new framework.

Handling code completion in this way is kind of complicated. The main problem is you can't do strict parsing because we are not dealing with complete statements. Instead we have to do our best at guessing what the you are aiming at writing.

So let me go through the changes in more detail what new features are introduced with this framework.

Smarter auto invocation

The most obvious change that people will immediately see is that as you start typing a select statement the moment you write "FROM" and then space you will be presented with a list of tables and views. Before 4.0 the only time we automatically invoked code completion was when you typed a dot. In 4.0 we have certain "hot tokens" that invoke code completion after you write a space as well. The full list of tokens isn't that important, but if you ever think we are missing something just let us know because it is very easy for us to change it.

Context sensitive object lists

We now look at the statement type to decide what kind of object list you probably are interested. For instance if you write "CALL" or "EXEC" you are probably interested in a list of procedures, when you are writing "UPDATE" you probably want a list of tables while when you are in the "FROM" clause of a select statement you probably want both tables, views and in case it's supported functions returning tables.

Context aware sub-select completion

Toad should now keep track of sub selects so that it knows which objects you can address when you are writing complex sub-selects as shown in the screenshot below.

Auto generated joins

When you are writing select statements we now automatically generate the full join statement based on foreign keys in the database. We can generate both the part following "JOIN", the part following "ON" or in case of a cross join the part in the "WHERE" clause.

Snippet code completion

In some cases the code completion generated still need you to fill in some extra data to be a valid statement. We now do this by inserting an auto generated code snippet. Specifically we use this when you are using code completion on code to let you fill in the parameters of the call we generate.

Complete statement generation

We can now generate the full statement for some statements after you have specified the database object to operate on. Specifically this includes update, insert and delete statements.

Good handling of owners

This only applies to SQL Server, but in 4.0 we really didn't have that good support for handling owners in code completion. As of 4.1 that we now handle owners in a really clever way. Basically it should now "just work". If SQL Server accepts the syntax we should handle it correctly.

Support for local variables in batches

On SQL Server we now keep track of local variables defined in a batch and includes these in the places where they make sense.

Options available for code completion

The option page for code completion has changed quite a bit between 3.x and 4.0.

First some things that haven't changed. The auto list members, quoting, casing, expand "*" and include system objects work exactly as before so I will not go into these (And they should be pretty self explanatory).

Item sort order

This setting now has one more item which is the default and that is the "Each category". This means that the code completion list is sorted per type of items. For instance in a select statement we start with the "*" and then columns followed by variables, snippets and a bunch of other stuff. Chances are that you are looking for the columns and in this case they will be at the top instead of being lost in the list of hundreds of function snippets also included.

Merge secondary items

When you invoke code completion in some cases we have items that are common to choose from and some items that are not so common. Normally the not so common items are not included in the code completion, but if you want to get to them you can still do so by choosing the last item in the list which says (More).

If this option is checked this means that we should generate the code completion list with all items right away instead of separating this into two different lists. This is the default.

Known issues

The one known issue in regards to code completion is that we currently do not honor the setting to separate statements with double newlines (On by default I think). For version control to function property with multiple statements in the editor you need to end you statements with ';' (Except for SQL Server which doesn't have this issue).

Sunday, October 19, 2008

Connection and transaction handling explained

In an application like Toad connection and transaction handling will invariant become a complicate affair. During the years we have been working on this we have tried to make it as intuitive as possible so that you usually don't have to think about it. However, in some cases you can still run into problems so this post will try to explain how we handle connections and transactions so that you can avoid the pitfalls.

All information in this article refer to the upcoming 4.1 (2.1 for TDA) release or later.


In Toad we distinguish between two different kinds of connections. The first on we refer to as a Toad connection which is our abstract representation of a user connecting to a database. Each toad connection can be represented by one or more database connections which are actual connections to a database. At a minimum Toad will usually use at least 2 database connections per Toad connection. The first one is used to fetch database meta data about the database. The second one is used for either the data tab or the editor you are looking at.

We need to have a separate connection to inspect the database because some databases (DB2 in particular) have an unnerving habit of creating locks even if you are just reading data so whenever we read data on these connections we always commit after we are done reading and if you were running Toad with auto commit off we would mess up transactions that were open.

By default each editor and data tab will use it's own database connection to keep the transactions apart. You can control this behavior through the option in the screen shot on the right. If you change this all data tabs and editors will share one connection. You will still have two connections though.

Depending on which database you are connecting to Toad does support to use command multiplexing by which I mean executing several statements as one on the same connection. Currently the only provider that uses this functionality right now is Oracle though. If you try to execute something in an editor while another statement is already running and the connection does not support multiplexing you will be presented with the dialog on the left.

Basically you have the choice of how you want to proceed. At the bottom you also see what it is that is already running on the connection. Most choices are pretty self explanatory except the one about opening up a new connection and execute your new statement on that connection. If you do choose this option the new connection will be the one that all the following executions in the editor will use.

When you close an editor the connection associated with it is also closed immediately unless there are open transactions on the connection. If there are transactions the connection will be closed when you commit or rollback the connection.

There are also a bunch of other places where Toad will allocate another database connection. For instance when you are applying changes from database object editors (This is platform specific) or debugging (Which has a tendency to need two database connections per debugging session).

If you want to see how many database connections are actually being used you can see that in the tooltip over the connection in the connection manager.

Current connection and document connection

Two things that many people have problems with is the difference between the current connection and the connection of the current document. The current connection is the connection that any new documents will have and also the connection currently being shown in the Object Explorer. You can also see which connection is current either by the connection being shown in the connection toolbar or through the icon in the connection manager.

The connection of the current document is shown in the lower right corner of the application (Shown to the right here). This button shows the connection of the current document. Also when you click it you can switch to other compatible (And open) connection depending on the document. Some documents don't have connections attached to them and in those cases this button will not be visible. You can also switch the connection of a document by right clicking on the document tab.

Normally this doesn't present any problems because when you switch the current connection we automatically select the first open document that has that connection and also when you switch document we also change the current connection to that of the new current document.

There is one case when the two can differ. If you have two open connections to two different database instances, let's call them A and B. Next you make sure you close all documents that have the database B as the document connection. Then while being on an editor with connection A as the document connection you use the connection toolbar or connection manager to switch to connection B. In this case since there is no document that we can switch to that has connection B as the document connection we will not change the active document. If you now try to execute something in the current document it will execute on connection A even though both the connection manager and the Object Explorer is showing connection B as the current connection. This is an unfortunate exception and there is really nothing we can do about it, we have tried a bunch of different solutions to this problem but they all turned up even more confusing to the end user.


Transactions in Toad is really tricky. You control transactions through the controls in the lower right corner of the main window (This has changed for between 4.1 and 4.0). It now looks like on the right.

The two commit and rollback buttons are only visible if you are not in auto commit mode. You switch auto commit mode by clicking the button to the far right and that part should be fairly self explanatory. When you switch auto commit on or off that setting is persisted per connection between sessions so be aware that if you forget to switch auto commit back to on when you close Toad you will still be in auto commit when you start the application back up again and connect to the same connection.

Auto commit is global for the Toad connection and will affect all editors and data tabs for a specific connection when you switch it. As of version 4.1 there is also a new item in this menu which allows you to switch one specific editor to auto commit without affecting the browser or other editors. Also when you use this feature it is not persisted to the next session and you will still be in auto commit when you restart Toad. Normally when you click the commit or rollback buttons it will commit all database connections for the current Toad connection. However, when you are in the auto commit off for the current editor the commit and rollback buttons only affect that editor (Even if you have more than one editor with this mode enabled for the same Toad connection).

All connections start by default in auto commit mode except for the Oracle platform which is in auto commit off by default (This is the platform that has the least problem with unexpected locks of the ones we support). This default (Which only applies when you add new connections in the connection manager) can be changed in the options as shown here on the right.

Inside Auto Commit

Auto commit is implemented in two different ways depending on the platform you are connecting to. For SqlServer and MySQL we rely on the implicit auto commit available on the server. For all other platforms auto commit is implemented by simply issuing a commit after we are done. There is an option to indicate what "done" in this case means. It's in the lower edge of the red rectangle in the screen shot above. You can choose to either commit after each statement or only after you are done executing the entire batch of statements you are executing (If you are executing a script for instance).

Pitfalls of not using auto commit

Some databases (Specifically SqlServer and DB2) have a problem with dropping locks around when you are running with auto commit off. This is particularly acute when you are issuing DDL commands because these have a tendency to create locks on the data dictionary which causes all activity in the database to lock up for all other connections than the one used in the editor. Since the database browser uses a different connection than the editor to fetch meta data about objects using the database browser in this case can completely lock up Toad. There is unfortunately very little we can do about this issue (At least as we have figured out yet), but it is an issue we are thinking a lot about.

Regardless of the database you are connected against though auto commit off can by it's very definition create locks that can stop other users to access parts the database. Because of this there is a timer in Toad (By default it is set to 30 minutes, but you can change this in the Database|Timeout page in the options). After this timer runs out you will be asked to commit or rollback your changes and if you don't reply within a 30 second time period your changes will be rolled back automatically. This is just to make sure you don't forget to commit changes in Toad, go home from work and then have the DBA yelling at you in the morning because you caused the night time batch runs to fail because of your lock.

Reducing startup time

For the upcoming 4.1 release I have actually been able to spend quite a lot of time to reduce startup time in Toad and hopefully there should be a quite noticeable difference. One of the changes made is to make the initialization multithreaded so the improvement should be even more pronounced if you have more than one CPU core.

There are a couple of other things you can do yourself in both 4.1 and versions before that to reduce startup time if you are annoyed by it.

  • Keep auto connect's to a minimum.
  • Don't show the web page on startup (This one will shave several seconds off your startup time because we don't need to load the IE component).
  • Disable the startup croak. This really doesn't save you much so if you don't mind it just leave it as is.
  • Don't both show connection manager tool window and new connection dialog on startup. The list of connections is a complicated control that takes a while to create so there really is no need to create two of them. Choose one way of opening your connections.
  • Try not to have every open tool window showing. Tool windows that are showing are initialized on startup and makes the application startup slower. Tool windows are not created until they are first shown so if you can't see them we don't waste time on them. Auto hide is also your friend here as the tool window isn't actually created until you zoom it in when auto hidden.
  • I might also add a note that collecting usage statistics takes so little time I can hardly measure it when profiling. Please enable it, it is really useful for us to evaluate where to concentrate our efforts for future development.

These two tips are only for advanced users who don't mind some more drastic methods to reduce startup time.

  • If you don't customize your toolbars and menues you can turn off saving and restoring these by unchecking this checkbox.
  • If you are ok with wasting some memory you can create a shortcut to run toad /prestart=true and then put that in your startup program folder. This will make Toad start pretty much instantaneous but the feature is not that well tested and might have some issues (Especially in regards to automation and running multiple instances of Toad).

Hopefully these tips will help you get to work faster in the future. As you can see from the previous post on the history of Toad for SqlServer we have already gone from 12 seconds to 5 seconds even though we have added tons of functionality.

Toad version numberings explained

Version numbers between the different components of the different products can be pretty confusing ever for us who work on it. Before 3.0 of the Core (The part of Toad that is shared between the products) each product had it's own release schedule and with that each had it's own release version of this. After release 3.0 we now try to coordinate releases between the different products (They are usually staggered with a few weeks, but they are all based off of the same core version now).

When I talk about versions in this blog I will usually unless otherwise specified refer to the Core version. This should in most cases correspond to the version of the product except for TDA in which case you just reduce 2 major release version.

Also to confuse matters even more a product can choose to skip a release (As for instance the DB2 product is doing now with the 4.1 release). Usually this happens because we need more time on that specific platform to get the features in that we want to have in a specific release.

If you are interested in what Core version your Toad is currently running you can check the .Net assembly version of the ToadCore.dll assembly of your application.

Here is a list of how the different versions of Toad relate to each others and the corresponding Core versions.

CoreToad for SqlServerToad for DB2Toad for MySQLToad for Data Analysis
2.0--2.0 -
3.03.0-3.0 - 1.0 1.1 2.0
4.1 14.1-4.1 2.1

1 Since these releases are not done yet this information is subject to change.

Toad nomenclature

We have a bunch of terms referring to different aspects of the Toad application internally and I thought I would share some with you because it's not that uncommon that it slips out in the Yahoo Boards when we talk about it so why not just go through them and explain them.

ActionRefers to any toolbar or menu item. The name action comes from the internal name from these through the plugin interface.
AssemblyThis is actually a .Net term that refers to a loadable chunk of code (Basically a dll file if you are used to normal Windows programming).
CoreThis refers to the part of the application that is shared between all products of the .Net Toads.
Database ConnectionWe use this term to refer to an actual connection to a database (In difference to a toad connection).
DOEDocument object editor. The window that is used to create or alter an object.
DOVDocument object viewer. The control that describes a specific object either in the RHS or the Object Details.
FacilityThis is an abstract representation of functionality that a plugin can provide to the core to extend it's functionality. Examples of facilities are version control provider, connection providers and support for file types.
LHSLeft hand side of the database browser. Also refers to the entire content of the Object Explorer.
Object PaletteUsed to be the name of the Object Explorer and some of us have a hard time learning the new name.
PluginA non core part of Toad. Plugins can extend functionality of the code by providing actions and facilities.
ProviderA provider is a facility that facilitates connections to databases. For instance the MySQL provider gives Toad the ability to connect to a MySQL database.
QP5The parser that Toad uses to parse SQL. The acronym stands for Quest Parser 5. This is a really cool piece of code that a team in Belgium is developing. It is used in several different Quest products.
RHSRight hand side of the database browser. Also the document containing the details for the Object Explorer. Contains a DOV.
Toad ConnectionWe use this term to refer to the one connection that the user has made to a database. This differs from a database connection which is an actual connection to the database. One toad connection can be represented by one or more database connections. I'm going to write a separate entry all about connection and transaction handling in Toad at some point because that is complicated enough for it's own article.
TDAToad for Data Analysis, our short hand acronym to refer to this specific product.
TRLToad Resource Locator. This is the way we pass around information about database objects between different parts of the application. Basically they are a string that uniquely identifies one database object in one database.

Command line reference

The documentation of what command line options are available on the Toad.exe is not necessarily that well covered in the documentation. True there is rarely any need to specify anything on it unless something goes wrong. I just thought I'd go through what is available.

First of all the format. Toad allows any parameters to be specified regardless of if it knows what they are or not because some plugins might want to read it later on unbeknown to the original startup code. All parameters are specified using this format.

toad /{parameter name}={value} {files to open on startup}

Also if you want to specify an option with space in it you can quote it like this.

toad "/{parameter name}={value}" "{A file to open}"

Here are the following parameters that we support in Toad as of version 4.1.

datadirDirectory Specify an alternative data directory for Toad to read it's settings from instead of the default location.
profile"true"Start Toad and generate profiling information. This is sometimes used by us if you Toad is behaving very slow to track down what is wrong. The information generated is included in the support bundle if it is available.
batch "true" Run toad in batch mode. This means that it will just open all available files without opening up the user interface and then exit. Used by automation.
prestart "true" Pre start Toad. This means that toad is run in the background to be available to "pop up" when you actually want it. This feature is never actually used but if you are ok with pre loading on windows startup you can add toad /prestart=true to your startup menu and have lightning fast startups when you actually need Toad. Will use memory even if you are not using Toad. This is how a lot of other apps fake quick startup times like for instance Adobe Reader.
installinit "true" Used by installation to initialize a cache of the available plugins of to the application. When run by this it needs to write to the install directory, but in case you have this which is normally the case you can rerun this as many times you want.
feedback "true" Enable usage reporting.
license "edit" Display the license entry form on startup.
transpose "1" Allow transposing when exporting grids. That means switching X and Y axises of the grid.
exportbenchmark "1" Generate a log file to help benchmarking the export engine. The file will be included in your next support bundle
excelverbose "1" Generate a lot of verbose info when exporting into Excel.
profilevc "1" Generate a profiling log to help benchmarking the version control code. The file will be included in your next support bundle
debuglog Filename Generate a log of some debugging events. The file will always be placed in the application data directory.
yukondebuglog "1" Generates debugging information for the SqlServer 2005 debugger. The file will be included in your next support bundle.
dbmsverbose "1" Generate very verbose DBMS_OUTPUT output.
oraclelastplan "1" Include the latest Oracle explain plan to your support bundle.
db2debuglogreports "1" Generate debugging information for the DB2 debugger. The file will be included in your next support bundle.
db2debuglog "1" Generate debugging information for the db2 command line executions. The file will be included in your next support bundle.

To end with an example running Toad like this will enable usage reporting and using a new application data directory and then open a file on startup.

toad /feedback=true "/datadir=c:\Users\MyUser\My Documents\ToadDir" "c:\Users\MyUser\My Documents\A Sql File.sql"

The history of Toad for SQL Server

I recently took some time to look through the different releases we have made of Toad over the years since we started and just thought I would share it with you guys. I chose the Toad for SQL Server release because that was the one which had made the most releases (For instance Toad for DB2 never made the 3.1 release). I have to say that looking at from where we have come Toad is becoming a lot more polished. Especially starting with 4.0 it seem that we have started putting more time into polishing stuff up than just trying to cram as much features as possible. It is also pretty remarkable how little Toad has changed from our first release. Even if you went straight from 1.0 to 4.0 you would probably feel pretty at home with the application even though there is a lot more functionality in it.

This only goes through some really superficial first impressions. There is tons of functionality that has been added all over the application which is not covered at all in this retrospect. Also this only covers the .Net based version of Toad (Everything except the original Toad for Oracle). Finally the Toad for Data Analysis obviously has a very different look even though it is based on the same code and that isn't covered covered either and it isn't that interesting either since it did not join "the family" until version 3.0 of Toad for SQL Server and as such hasn't seen that much change.

Toad for SQL Server v1.0

When you start the app up you get nothing but the startup page (Which is interestingly a different page in this version than all the other versions) and a new connection dialog. Also fetching around a 200000 record long query takes over 1 minute in this release (It’s also N*Log N so fetching 500K takes over 5 minutes). This is also the only release we made that had the history node in the connection manager.

Toad for SQL Server2.0

Very small visual changes for this release. We added the composite image manager for better icons in the object palette. Also switched out SandDock to UIDock for the tool windows. We also fixed the fetching speed when you fetch everything we are pretty fast in this release, you don’t get any updates until you fetched all the data though. When you fetch just the first 50 rows and then continue we are still really slow. If you look closely you can also see that we switched the tab control in the object palette, added filtering and the column list pane at the bottom. We also added the connection output to the editor. In this release we finally managed to get NGen to work properly so startup time went from 12 seconds in 1.0 to around 9 seconds in this release.

Toad for SQL Server 3.0

This is the first release that figured out that my installed SQL Server instance is called SQLEXPRESS automatically. It also the first with FastData in it so fetching is now pretty fast (Pretty much as fast as before but with updates as you are fetching. This is also the only release which has indication of not null (The blue column header).

Toad for SQL Server 3.1

The most obvious changes here is the new connection tool bar (Which replaced the old connection bar). We also have the new quick search functionality implemented here. We have also added spooling to FastData so we now fetch the 200000 row query in about 5 seconds. This is the first release which doesn’t limit results in the editor by default any more.

Toad for SQL Server 3.2

Here the most obvious change is the panes of the editor. Apart from that there are few visible changes from before. This was mainly a stability improvement release.

Toad for SQL Server 4.0

Now this one is different! First of all we trimmed the grids so that you see a lot more rows from the start. The tabs in the editor has been tweaked to something that most people will find more useful (And they also follow the skin of the main application). The browser is in tree view. You also no longer get the configuration wizard on start up. The toolbars are rearranged so you can see all the buttons (We also no longer show the connection toolbar by default). A lot of the icons have been cleaned up. This is also the first release where the two tool windows showing on the left show up that way by default (In all previous screenshots I opened and rearranged them manually). And also we add the auto hidden tool windows to the right of the screen. And finally we changed the name of the object palette to object explorer.

Toad for SQL Server 4.1 Beta

An interesting change here is that we fixed a bug all the way from 1.0 of the product to not apply a skin by default. We also fixed the “edit” indicator button on grids. You can also see that the connection output is now gone and replaced with the messages tab. More work on cleaning up icons. We also see that we don’t expand the database node by default anymore in difference from 4.0. Another change in the 4.1 release is that on my machine this starts in around 5 seconds. Every release up to this release has started in around 9 seconds except for the 1.0 release which took 12 seconds.

Starting this blog

Every once in a while I've been writing Toad stuff on my personal blog and I figured it is time to stop doing that and try to do this blog into something a little bit more useful.

I will try to write tips and tricks about how to use Toad as I can think of them.

I'm one of the original developers of the .Net versions of Toad (All products except the original Oracle one) and currently work on what we internally call the "core" which means the piece of the application that is shared between the different platforms.

The entries on this blog are also posted on ToadWorld. For feedback and direct communication with all the developers of the product the best venue is till the Yahoo Groups. The information here has not gone through the normal peer review process of our normal documentation and sometime it might be about features that have not been properly tested (And that is why we aren't documented because we aren't ready for people to start banging on it). So use the information you find here at your own risk. Also please excuse me for all my spelling and grammatical errors, English isn't my first language (Truth be told I'm not that great at spelling in Swedish either).

I have a bunch of stuff I want to write about already so originally there will probably be a bunch of postings as I start out (Assuming I stick to it). After a while it should settle down a bit to just a few posts a month as I've worked through my backlog.