This past week I was very blessed to be able to attend JP Boodhoo’s Nothin But .NET Bootcamp in Philidelphia, PA.  It was an intense week of advanced coding that I’m not likely to forget anytime soon.  JP is a very upbeat and passionate developer with a deep understanding of .NET, OO design, and BDD.  He is also a great communicator, teacher, and individual, so you can’t ask for a better combination to bring you through an advanced .NET bootcamp experience.

The bootcamp experience really started before the class even started.  JP sent out some material about a week before the course.  When was the last time you had a technical training that you need to do a bunch of prep work to even be ready to show up for the first day? He also sent out a warning about the hours that the course normally takes up to make sure everyone was expecting this to take up every ounce of time and energy they could give.  I had already heard about these things before, but just hearing about it is just not the same as experiencing it.

The prep work consisted of a bunch of PC prep work (software setup and configuration) as well as a sample project that we were going to start the week with. The project simply had a bunch of failing unit tests.  We simply had to make the tests pass and refactor.  There was lots of refactoring that could have been done and after a few hours I stopped.  We started Monday with someone’s version of this project and it just took off.  I was shocked at how fast JP could take the project that look very similar to my version and transform it into a far superior project with concise code that read beautifully so quickly.  He immediately starting introducing new concepts to me and I knew what others had said about this week was going to be true. JP never really slowed down until day 4, but by then it was time for the students to drive the course to completion.

The week was intense in every sense.  The hours were long. My days finished at about 11:15pm, 12:00am, 1:30am, 2:15am, and 9:30pm, and I left early on the last 2 nights. There wasn’t a lot of fluff time in there either.  Sure, we had some nice sized meal breaks but the group stayed together for the most part. It was a real test to be able to keep focused and concentrate. To be honest, I really failed that test at the end of the 3rd day, but JP tries to record screencasts of everything so I can go back and re-watch what I stared blankly at live in person.

The material was deep and I didn’t find much of anything I didn’t have to follow carefully to understand.  Through the first 3 days, he mixed in a nice amount of coding with giving the class a chance to work through small bits.  This usually consisted of JP writing a test and having us make it pass or having us write the test and make it pass for the next small feature.  He gave us a few more lengthy to-do items but we worked in small teams and I was always surprised that we could start with 4 people who really had no idea where to start but each time complete the exercise without getting JP to do it for us.  These small exercises were easily the best part of the course for me.  Each time I worked with different people, interacted with different people and interesting ideas, and was encouraged to see how most everyone was able to contribute to make the team successful.  The short time slot of an 2 hours or so just seemed like a sweet spot to me.

Starting on the 4th day, we were expected to just work with our team and complete the project we had been working through since Monday evening and make it special.  This was fun as well, but it felt different to me for some reason.  It was interesting to see how our team split up the work and how we attacked the problem.  We spent from Thursday after lunch until we quit early the next morning and then we continued with it on Friday after lunch until I left Friday night. 

I really enjoyed working and talking with other developers with a hunger to improve their craft and build great software. The people who want to come to a course like this are really striving to improve and it makes for a great experience. I learned a lot through the course of the week and I left encouraged to continue to improve as a developer. I leave with a number of areas I now know I need to focus on and a good place to start that learning.

Thanks to JP for a solid week, a great experience, and great foundation for continued work in my core .NET skills and testing practices.

The only other from my class who I know of who has blogged about the course was Rob Reynolds.  Rob gets into much more of the actual content details in his posts if you are interested in the actual course content.

I started working with VistaDB Express this spring as a data backend to use with BlogEngine.NET.  I wanted to make a new data provider for a session I was giving at code camp and wanted to get familiar with a database I didn’t know.  I ended up choosing VistaDB because it looked interesting and because I found so little information about using it.  I also wanted to know why Telligent picked it for Graffiti over something else. 

While I was considering what database to use, SQLite was recommended to me be two different people.  I had recently read a few articles on getting started with it.  It looked interesting and was the other choice I gave consideration to.  Since doing my talk and spending a nice amount of time working with VistaDB, I’ve also had a chance to work with SQLite a bit and thought I’d share my thoughts on the two databases. 

Both SQLite and VistaDB Express are lightweight file based databases that work very well.  They are similar but different enough that there are a few things to consider when thinking about them.  Both have .NET support via ADO.NET data providers and I’ve had no problems with either of them.  Both are small in size and in the small data sets I’ve worked with both have performed very well.  (I read somewhere that SQLite performs better with larger data sets, but I’ve never seen any real stats on the matter.)  SQLite and VistaDB both have nice GUI admin tools available to work with and both databases have been easy to use overall.  Both have small runtimes, work in mono, and support transactions, I believe as well.  Now onto the differences… 

Cost

SQLite is free to use for any purpose.  VistaDB is a commercial product and VistaDB Express is a free for non-commercial use product that requires a link back to the company.  This is a huge difference for some people and is the main strike I have against VistaDB.  If I had a paid commercial product however, the cost of VistaDB is minimal enough that I would not let it sway me too much.  For my personal consulting work, I’m not too excited about the $299 price.  VistaDB Express is a nice alternative for non-commercial use, but the required link isn’t ideal for every circumstance.  (You’ll notice I have the link in the footer of my blog.)

Data Types

I’ve found that VistaDB mirrors SQL Server’s data types very well.  Since I’ve done most of my database work using SQL Server, this suits me very well.  SQLite is more similar to MySQL as far as that goes.  I’m not a MySQL expert (or to be honest even a fan) so take that with a grain of salt.  There is nothing wrong with the data types being different, they just are and it is a distinction.  For me, I’m more comfortable with the SQL Server similarity, but I will freely admit it is a minor issue.

Scripting

Both SQLite and VistaDB support most of the standard SQL I’ve run against them.  I recently noticed that SQLite did not support the ability to change a column in a table via ALTER TABLE which I found to be a bit of a nuisance.  (It seems lame to tell BlogEngine.NET users they have to manually change a data type in a table in the new upgrade.)  Other than that however, I’ve had no issue with either one.

GUI differences

As I said earlier, both SQLite and VistaDB have nice GUI admin tools.  As an open source product with a big following, SQLite has a few GUI admin tools to choose from.  I personally have only ever tried SQLite Administrator.  I have no idea if there are better tools so what I say is based on my work with this tool.  From a functionality perspective, I’ve been able to do basically what I’ve needed to do in both interfaces.  I can honestly say they are both fine tools for the job.  That said, I much prefer my SQL Server Management Studio to both of them. 

Just as in the data types though, VistaDB’s Data Builder tool is a little more SQL Server like.  The look is more similar as is the organization.  It felt a little more comfortable to me as it was more like what I’ve been using for years.  I particularly liked the Data folder under each table for getting to my table’s data quickly. There are a few quirks however including an annoying laptop issue.  (When I have a second display on my laptop, I often move the VistaDB window to the secondary display and close it from there.  When I next open it when the second display is not connected, it opens off the screen and I need to edit the registry to bring back over.)

As I said, the SQLite admin tool was very nice too.  While the look and organization was a bit different, the Edit Data tab in the query area is very nice.  It is a handy way to edit and view/filter data.  There was also a possibly helpful export to excel option easily available.  The interface didn’t seem to have as many quirks but I have spent less time in it.  I found an oddity with editing a table, but it was very minor.

Encryption

One other thing of interest that I found was that VistaDB has an encryption option which will encrypt your database with a password.  In a file based database, this seems nice.  I didn’t see that SQLite had this built in, but I could be wrong about it.  I did see some commercial tools to help with this though.

Documentation

I’ve spent only a little bit of time searching for documentation, looking for examples, and reading forums for each of these products.  My little experience however tells me that SQLite has VistaDB beat in this area.  My google searches regarding SQLite usually brought me right to what I needed and likely had the answer below it as well.

I found a bunch of getting started guides for SQLite and nothing for VistaDB Express besides what comes in the download.

It wasn’t hard to get started with VistaDB however, but a bit more information would have been nice.

Summary

As you might guess from my notes above, I have a slight preference for VistaDB overall.  The cost of VistaDB is an issue and the express version is not an option in many situations you find yourself building software.  There were a number of small things I liked better about VistaDB though and they add up.  The information out there on the web about VistaDB is lacking however.  Hopefully, this will improve with time.

SQLite is very solid and other than the ALTER TABLE issue, I’ve really enjoyed using it too.  It has many things going for it.  I know I can pick up a mac admin tool and as I have a MacBook Pro, this might be a nice option down the road.

Both options are very good and I’ll likely be using both in the future.

After a few requests, I decided to go back and do another data provider for BlogEngine.NET.  This time around I’m using SQLite.  SQLite is a file based format very similar to VistaDB Express and it has no restrictions .  It is another fine option for blog data and very easy to work with.

Once again, this is a complete provider setup.  It will store all your blog posts, pages, profiles, users, roles, and settings.  It could be partially implemented by making changes to the default providers in your web.config if you desire.

The process for getting setup is very easy.  The instructions are assuming you have BlogEngine.NET setup already.  If you don’t please check out the initial setup screen cast to walk you through the process.  If you already have an existing blog, be sure to backup before following these steps.

1. Download the SQLite database provider for BlogEngine and unzip it.

2. Download the SQLite ADO.NET Provider binaries.

3. In your SQLite ADO.NET download, find the System.Data.SQLite.DLL and add it to your blog’s bin folder.

4. From the BlogEngine download, copy the BlogEngine.s3db file to your blog’s App_Data folder.

5. Next, replace your blog’s web.config file with the new web.config file from the BlogEngine download.

6. Browse out to your blog and you should see the BlogEngine with SQLite welcome post. 

7. Your User security has been reset, so login as Admin (with the password, admin), add new users, and change your password.

That is it.  You should be now blogging with data stored in SQLite.

If you are reading this blog regularly, you are now likely tired of the database themes going on this week.  First, it was SQL Server and BlogEngine.  Then VistaDB Express and BlogEngine.NET complete with download.  Today, I’m moving on to MySql.

Let me start this post by admitting right up front that I have almost zero experience with it.  I didn’t even get it installed until last week and that was just to make sure the BlogEngine.NET could work with it.  So instead of completely embarrassing myself by doing a screencast with something I know nothing about, I figured I’d just write up a guide on how to do get started with BlogEngine and MySql and embarrass myself with text.

Requirements

I’m expecting you have BlogEngine.NET installed with the default settings and providers.  If you need help getting to this point, you should check out my initial installation screencast.

Second, I’m expecting you have a MySql database setup and some administration tool to work with.  If you need help getting to this point, I wish you the very best. :)  Actually, I was truly miserable until Ruslan Tur recommended Toad for an admin tool.  This made my experience much, much better.

Creating a Database

You’ll need to create a database or have a database to put the BlogEngine table in.  I have created a script to get the initial tables and data created for you.  Just execute it against the database you want to use for BlogEngine.NET.  Download the script here.

Add the MySQL dll to your bin folder

You’ll need to download the MySQL Connector/NET 5.1, find the MySql.Data.dll, and added to your bin folder.

Update your web.config

I’m including a sample web.config for you to download, but I’ll go through the changes here. (Download Sample web.config.)

First, we need to let BlogEngine know about this new MySQL dll we just added.  This is done by adding the assembly to the list of assemblies and then adding in the system.data section to let BlogEngine know where it will find the MySQL DBProviderFactory.

   1: <system.data>

   2:     <DbProviderFactories>

   3:         <clear />

   4:         <add name="MySQL Data Provider" 

   5:              invariant="MySql.Data.MySqlClient" 

   6:              description=".Net Framework Data Provider for MySQL"  

   7:              type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data, Version=5.1.6.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />

   8:     </DbProviderFactories>

   9: </system.data>

  10: <system.web>

  11:     <compilation debug="false">

  12:         <assemblies>

  13:             <add assembly="MySql.Data, Version=5.1.6.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D"/>

  14:             <add assembly="System.Management, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

  15:             <add assembly="System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

  16:             <add assembly="System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

  17:             <add assembly="System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

  18:             <add assembly="System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

  19:             <add assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>

  20:             <add assembly="System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

  21:         </assemblies>

  22:     </compilation>

  23:     < ....snip..../>

  24: </system.web>

Then, you will need to add your connection string to your connectionString section.

   1: <connectionStrings>

   2:         <clear/>

   3:         <add name="LocalSqlServer" connectionString="dummy"/>

   4:         <!-- Mono complains if LocalSqlServer isn't specified -->

   5:         <add name="BlogEngine" 

   6:              connectionString="Data Source=MySQLServer;User ID=user;Password=password;persist security info=False;initial catalog=BlogEngine;" 

   7:              providerName="System.Data.SqlClient"/>

   8:         <add name="MySQLDB" 

   9:              connectionString="Server=localhost;Database=blogengine;Uid=beUser;Pwd=beUser;" 

  10:              providerName="MySql.Data.MySqlClient"/>

  11:     </connectionStrings>

Lastly, we need to link up the BlogProvider, the MembershipProvider, the RoleProvider, and the ProfileProvider.  The BlogProvider section is near the top of your web.config in a BlogEngine section.  The other 2 can be found in in succession down much further in the file.

   1: <BlogEngine>

   2:     <blogProvider defaultProvider="DbBlogProvider">

   3:         <providers>

   4:             <add name="XmlBlogProvider" 

   5:                  type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>

   6:             <add name="DbBlogProvider" 

   7:                  type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" 

   8:                  connectionStringName="MySQLDB" 

   9:                  parmPrefix="?"/>

  10:         </providers>

  11:     </blogProvider>

  12: </BlogEngine>

   1: <profile enabled="true" defaultProvider="DbProfileProvider" inherits="BlogEngine.Core.Web.AuthorProfile" automaticSaveEnabled="false">

   2:     <providers>

   3:         <add name="XmlProfileProvider" 

   4:              type="BlogEngine.Core.Providers.XmlProfileProvider, BlogEngine.Core"/>

   5:         <add name="DbProfileProvider" 

   6:              type="BlogEngine.Core.Providers.DbProfileProvider, BlogEngine.Core" 

   7:              connectionStringName="MySQLDB" 

   8:              parmPrefix="?" />

   9:     </providers>

  10: </profile>

  11: <membership defaultProvider="DbMembershipProvider">

  12:     <providers>

  13:         <clear/>

  14:         <add name="XmlMembershipProvider" 

  15:              type="BlogEngine.Core.Providers.XmlMembershipProvider, BlogEngine.Core" 

  16:              description="XML membership provider" 

  17:              passwordFormat="Hashed"/>

  18:         <add name="SqlMembershipProvider" 

  19:              type="System.Web.Security.SqlMembershipProvider" 

  20:              connectionStringName="BlogEngine" 

  21:              applicationName="BlogEngine"/>

  22:         <add name="DbMembershipProvider" 

  23:              type="BlogEngine.Core.Providers.DbMembershipProvider, BlogEngine.Core" 

  24:              passwordFormat="Hashed" 

  25:              connectionStringName="MySQLDB" 

  26:              parmPrefix="?" />

  27:     </providers>

  28: </membership>

  29: <roleManager defaultProvider="DbRoleProvider" enabled="true" cacheRolesInCookie="true" cookieName=".BLOGENGINEROLES">

  30:     <providers>

  31:         <clear/>

  32:         <add name="XmlRoleProvider" 

  33:              type="BlogEngine.Core.Providers.XmlRoleProvider, BlogEngine.Core" 

  34:              description="XML role provider"/>

  35:         <add name="SqlRoleProvider" 

  36:              type="System.Web.Security.SqlRoleProvider" 

  37:              connectionStringName="BlogEngine" 

  38:              applicationName="BlogEngine"/>

  39:         <add name="DbRoleProvider" 

  40:              type="BlogEngine.Core.Providers.DbRoleProvider, BlogEngine.Core" 

  41:              connectionStringName="MySQLDB" 

  42:              parmPrefix="?" />

  43:     </providers>

  44: </roleManager>

Configuration

Once you have these changes made, you can browse out to your web site and you should be greeted by a new welcome message.  Just as with the SQL Server setup, you’ll be missing your widgets.  So you can login with user “admin” and password “admin”.  Add your Administration widget and then refresh your page to see the full menu.

At this point, you should add users and change the admin password.

It really is fairly easy to get set up especially since you can copy and paste the new sections out of my sample web.config.  I also wanted to start that I save a bit of time getting the install script done by starting with the script I found as part of this post by Mr. Wize.  I added the new tables and initial data, but the initial work was done by him.

Now that the latest version of BlogEngine.NET is out, it is easier than ever to get your blog running with VistaDB Express.  I’ve been using VistaDB Express with BlogEngine.NET for a little while now and just love it.  I’ve become a fan of the lightweight, file based database for a single user blog.  I think it is a perfect way to store your blog data.  Enough of my gushing already, let’s get on the real info.

Getting BlogEngine.NET 1.4 to work with VistaDB is super easy, but will require you to upload a few more files.  I’ve put together a new screencast that will walk you through the steps, show you exactly what to do and what changes are being made.

It is incredibly simple however.  You simply download the BlogEngine 1.4 VistaDB Express Pack, unzip it, upload 3 files, and enjoy the goodness that is VistaDB Express and BlogEngine.NET 1.4.  In the screencast, I also take a little time to walk you through the main changes made to the web.config to make this work.

If you are starting a new BlogEngine.NET blog, I strongly recommend it.  If you already have a BlogEngine.NET blog and want to convert over to it, I’ll get to that soon.  I promise. :)