RSS
 

The Duck House

26 Jul

Our nice little "play yard" for the ducks.

After about two weeks of planning, and a lot of work over the weekend, our ducks have finally moved downstairs to their “play yard”, or “duck house” as I like to call it. Jen is charting the adventures of the ducks here.

Everything came together nicely, and pretty cheap, thanks to some extra fence that family had and Jen’s amazing find of a dog house up on Craigslist. We reused some of the fence posts from the yard and it cost me about $45 to put together the two gates (yes, there’s a little gate to lock the ducks in safely at night.

While we had debated about exactly where to position the duck yard, we came to the conclusion that under the deck was perfect because it would be more protected during the winter from the snow, there was already a roof and a back wall, which meant less material to purchase, and the space wasn’t being used anyway.

The one thing you can’t see is that one side of the roof was ripped open and hinges put in so that we can easily get into the house to clean it out and (hopefully) get eggs in the next couple of months. The other thing you may or may not see in the photo is the big galvanized tub that serves as a “duck pond” hiding right behind the green branch in the lower right hand side of the photo.

The ducks love their new space. There’s lots more room to run around in, though they spent nearly all of their first afternoon sitting in their pond, floating around and ducking under to clean up. In another week or so we’ll let them start exploring the entire back yard.

As always, there’s a few minor things to update. There are some slight gaps from the roof to the fence towards the front of the yard where there was a bit of a downward slope. I just need to get a little more fence or lattice work put there to keep extra critters out. There are a slew of nails in the roof from the rain tiles installed, and I need to clip those off.

All in all a very successful project, a lot of hard work, and a lot of fun. I tend to spend my weeks hacking the matrix of 1s and 0s and the weekends hacking lumber, logs, or weeds to seek some balance. 8^D

…oh, and of course no duck entry would be complete without showing the girls and their pets:

The girls and the ducks.

I think this is looooove!

 
View Comments

Posted in Handyman Tricks

 

Removing rows with duplicate Ids in SQL Server

20 Jul

Yes, you say it can’t be done. You have a table where the Id field is set to be unique and the primary key, yet SOMEHOW there are two rows in a content table that have the same Id. When you try to delete one of the rows, it says it can’t delete the row because there are duplicate unique keys. [Then why did you insert the extra one in the first place!!!!]

<Queue spontaneous head pounding against the wall />

On an interesting side note however [Yes, I tangent a lot], it appears the culprit was SQL Server Management Studio and its ability to allow you to paste data from Excel into the data view, thus inserting extra rows. Maybe it is temporarily disabling all constraints on the table behind the hood, I’m not sure, and I still need to duplicate it, but we saw an instance of this once before that seemed to have the same path.

I’m aware of the internal fields, such as row_number, that are available for queries, but I wasn’t sure how to access it in this case. After passing word on to our almighty DBA, he did some research and came back with a really simple SQL statment that does the job for us:

SET ROWCOUNT 1

DELETE FROM dbo.content WHERE content_id = 40598

Problem solved and we cleaned out a good handful of records in this manner. What the first line of the script does is restrict any operations to stop after the first row is processed. Our second statement deletes a record (which you would expect), but since our rowcount statement halts the gathering of any additional records for processing after the first one, the constraint isn’t triggered.

If you’re stuck in a duplicate Id bind, let this one do the trick for you.

 
View Comments

Posted in Coding

 

Changing Log4Net Configurations Dynamically

15 Jul

One  issue I’ve run up against over my time using log4net is being able to change the logging levels dynamically. When I build an application, I put in both top level Error/Fatal log messages, but I also put Debug/Info level messages when issues arise that I need to handle (check out my Quick-Start Guide if you’re curious on how to set this all up). By default I have the logging level set to WARN, but I want to be able to quickly see DEBUG level messages when things aren’t working properly.

Changing the configuration on the fly works fine in a development environment, but in a production environment, I don’t have access to the configuration file to make the proper modification due to the security restrictions we have in our environment. In addition, if I’m working on an application through a web host, it would be nice to change the configuration without having to FTP into the server.

Thanks to the LINQ to XML features announced in the .Net 3.5, being able to change the configuration on the fly became really easy. To note, I’m sure there were ways of dynamically updating the configuration pre-3.5, but parsing XML documents and searching/updating them can be tricky and time intensive at times. Not so anymore.

Without going into too much detail, the solution comes through using the XDocument object and the . For instance, if I wanted to get the logging level being used, and I know the proper XML path to the node, I can use the following code:

ContentDoc = XDocument.Parse(File.ReadAllText(LogPath));
Results = ContentDoc.Descendants("log4net").Descendants("root").
             Descendants("level").Attributes().First().Value;

Similarly, each the entire document can be exposed as an enumerable XElement object, so you can iterate through a collection of appenders, looking through the proper filename value through the following code:

XDocument ContentDoc;
IEnumerable<XElement> DocPoints;

ContentDoc = XDocument.Parse(File.ReadAllText(LogPath));
DocPoints = ContentDoc.Descendants("log4net").Descendants("appender");
foreach (XElement Item in DocPoints)
{
   if (Item.Attribute("name").Value == "XmlSchemaFileAppender")
   {
      Results = Item.Ancestors().Descendants("file").Attributes().First().Value;
   }
}

From here you can see that accessing and modifying values becomes quick and easy to do. The XDocument object also allows you to easily add new nodes to an existing document. You could easily add an ASP.Net appender, or any other appender to the system on the fly, or enable/disable appenders on the fly as well.

But for today, we’re going to keep things simple and only worry about updating the logging level. This way you can easily make your application dump out diagnostic data in the production environment and then revert back to its simple error logging after you have the necessary data.

Most of the code is given to you above. The final step in the process is to update the log level value and then write it back out to an XML file. The XDocument object provides for this as well:

ContentDoc = XDocument.Parse(File.ReadAllText(LogPath));
ContentDoc.Descendants("log4net").Descendants("root").
                 Descendants("level").Attributes().First().Value = "DEBUG";
ContentDoc.Save(LogPath);

It really is that simple. The trickiest part of the whole process is learning how to navigate through the XML document with the proper use of the Descendants(), Ascendants(), and Elements() structure used within the object.

In an effort to share the love, I’ve written a really simple ASP.Net application that will show demonstrate all of this, and give you the complete code blocks to make this happen for you. There are two items to note when setting up your own configuration:

  1. The configuration file needs to be in a separate [Assembly].dll.log4net file. Modifying the web.config file on the fly will cause the application to restart its worker process, and eliminate the goals in mind. See my Quick-Start Guide if you need details on setting it up.
  2. You will need to make sure your ASP.Net application has proper write privileges to your configuration file, otherwise the process will file when it attempts to write to the file.
  3. The log entries generated are using the built in lo4net XML format, so you’ll either need to read the XML or maybe take a peek at an old and ugly (but still usable) log4net viewer app I wrote 8^D.

The apps have been tested and compiled to use the Visual Studio Development Server, so you should be able to unzip, fire up the solution, and run the project.

If you run into some additional clever uses with XDocument and log4net configuration, by all means share them here. Hopefully I can get a really robust configuration tool developed to extend things even further.

Enjoy!

DynamicLog4NetVB_2008 (240 KB)
DynamicLog4NetCS_2008 (211 KB)
DynamicLog4NetVB_2010 (389KB)
DynamicLog4NetCS_2010 (350 KB)

 
View Comments

Posted in Coding

 

Quick Tip: Taking your ASP.Net Application Offline

08 Jul

ASP.Net is friendly enough that if you have to make a change to your application, you can simply copy the files up to the server location and be done with it (the noted XCopy method). A user currently using the application will work with an old copy of the DLL until their session is finished, whereas the new users will get a new copy of the DLL.

There are times, however, where a more robust update process is involved (adding some database entities, making sure session data is completely flushed, adding resource files) and you need to take the user offline. If you are running your own server, or have a single application on the server, this is a pretty simple process. You can simply shut down IIS altogether, or have the IIS entry redirect to a different page at the domain level, that way users can’t get into the application through any vector.

If you’re on a shared host, or have multiple applications using the same application pool, or just want a really quick way to take your application offline, there is a simple method by using one single file. I discovered this trick about a year and a half back while working on my netrep project and we just used it again the other day here at work.

Starting with .Net 2.0, if you need to take a web application offline, you simply need to upload a properly formatted HTML document named app_offline.htm and IIS/ASP.Net Worker Process handles the rest. Any users, current or new, reaching the application will be presented with your offline HTML page, as well as send a Server 200 response back to the browser. When you’re ready to bring the application online again, simply remove the file, or better yet, rename it to app_offline_disabled.htm or something else and save it for the next time you need to take things offline.

That’s it! No mess, no fuss, IMMENSE benefit! There were even some delusions of grandeur in my group about making a simple web application for our server admins to to allow them to simply check the web apps that need to go offline when an update is being made and it would automatically process these files.

The one small caveat to this is that you have to make your HTML file greater than 512 bytes in size. Otherwise, Internet Explorer (and potentially other browsers) will attempt to display a “friendly” error message to you, like they would on other sites when encountering 400, 200, 500, and other server return codes.

Enjoy!

 
View Comments

Posted in Articles

 

Migrating BlogML to WordPress 3.0

03 Jul

Update: My plugin has been approved by WordPress! I’ve updated the documentation and links accordingly.

As part of my migration to WordPress 3.0, I needed to get all of my posts migrated over. My comments were stored via Disqus, and I’m working with them on migrating that data to the new URL slugs.

BlogEngine.Net uses BlogML as their sole export format, which became a little tricky, since there is still no WordPress importer built in to handle this.

As is with most things in life, we are all standing on the shoulders of giants. In this case, Aaron Lerch was my giant and he had created a great BlogML importer, which included all of the necessary XPath information needed to import blog entries.

The only problem is that the plugin was created to work with WordPress 2.6, and the format for importing content has changed since then. The  ‘wp-admin/imports’ folder no longer exists in 3.0, and it could have been earlier than that as well.

An initial peek of the importer code didn’t yield any results to me, but installing the simple RSS importer and examining that code allowed me to see what was going on. With the newer format for importing, you downloaded a plugin, which upon activation registered itself with the import module used in WordPress. All I needed to do was to put this registration wrapper around the existing code, update some documentation, and voila, a working BlogML importer!

Just as my giant has opened the code up, I’m doing the same, for any BlogEngine.Net,  SubText, or other BlogML formatted folks out there that are thinking of migrating to WordPress.

Before importing, you’ll want to go into your BlogML file and look for any file or image references that exist and update them accordingly. For instance, with BlogEngine.Net, it uses a ‘file.axd’ HTTP helper to deliver a lot of its files. You can always update this data after the import. It is up to you.

Using the importer is rather simple:

  1. Log into your WordPress site and go to the ‘Plugins’ section.
  2. Click the “Add New” button and search for the term “blogml”.
  3. Find the ‘blogml-importer’ plugin and install it.
  4. Activate the plugin.
  5. Go to the Tools->Import screen, and select the ‘BlogML’ option.
  6. Follow the directions to complete the process.

As an added bonus (thanks to Aaron), the import process will create a CSV file that maps the old permalinks found in the BlogML file to the new permalinks that WordPress generated. It will also give you the option of mapping posts to a current user, or to create a new user account for them.

I ran this process and had all of my posts migrated over in a few seconds. Granted I only had 65 posts, but it still saved me a lot of time. I’m still doing a bit of image/link cleanup, but that is simple to do.

One other important item to note is that categories and tags may or may not be properly imported. In my case, none of my tags came over, and my categories came over named as GUIDs. Renaming the categories didn’t take long and I’ll simply need to retag my posts. Again, considering the time it would have taken me to renter all of my posts (and I know others have lots more), I’m not too worried about this.

I hope this helps other folks out their with their WordPress migrations. I’m hoping to look through the import code again, and work on getting some of the category/tag issues resolved. I may even try to do some kind of auto-detecting on the image/file links to provide a proper “remap” option like with the user import. Once the plugin is approved in the codex, I’ll update my link to point there.

Enjoy!

If you want to download the plugin go to the direct link here.

 
View Comments

Posted in Coding

 

Bienvenue WordPress!

02 Jul

Well, here I am on WordPress 3.0.

Some of you may be wondering why I’m rolling a new blog engine, and a PHP based one at that [yeah Mr. .Net Junkie!].

I have nothing against BlogEngine. I love it. I recommend it for any .Net folks out there that want to do get into blogging and tweak with their themes/plugins a bit. You’ll feel quite at home there. I was impressed with the layout of it when I went through the process of migrating Disqus into my theme.

Lately though, my side work has drifted into the realm of WordPress (through my support of Evangelical Outpost as well as some upcoming work with The Prescott Project). I felt it best if I could get some more hands on work with WordPress and PHP. As they say, “Never stop learning” right? I’ve already gotten back in the groove a bit by modifying a BlogML import script out there to work with 3.0 so I could migrate my posts in. More details on that later.

Enjoy!

 
View Comments

Posted in General

 

Summer Reading

11 Jun

Just a quick note that I had a small mention on the Evangelical Outpost site where I am helping keep all the technical bits in order. You should take a peek at the list and find some good summer reading.

I’m already about half way through Dallas Willard’s The Divine Conspiracy and it is blowing my mind! There is so much stuff I missed the first time I read it about 10 years back and my outlook on things is changing. Give it a read!

As a side note, I was also fortunate to get a small “feature” to post my thoughts on the LOST series finale, if you’re curious.

 
View Comments

Posted in General

 

Is the API the next killer app?

01 Jun

The ?killer app? is a term for those of a geekish lean that describes the ultimate application out there that you simply can?t live without. It is typically used identify a utility or program that provided countless opportunities to create new things, or tweak out your computer, or give you immense flexibility over content consumption. If was a mark of good standing if your application was tossed around in the question, ?Is this the killer app?? I dreamed I could write something remotely close to this.

By most references, VisiCalc was the first killer app since it open the doors to spreadsheets for the average user on a computer. Around the time I was getting into computers (the glorious age of DOS 5.2 of 14.4K baud modems), you could look to archive tools, such as PKZip, as the killer app that allowed people to move large sizes or numbers of files around with minimal hassle. Around this time I also found QModem to be my own killer app, since it allowed me to connect to my local BBS with plenty of custom scripting options [yep, I scripted out my own ZModem downloads before the protocol came standard 8^D].

As computers became more ?average Joe friendly? (no derogatory implications in any form), the killer app migrated out a bit more into the public sphere. Compuserve, then AOL. Became the killer app because users could send messages to friends, shop online, and check out special products from vendors. I?m sure there?s plenty of folks who remember when TV commercials had the tagline ?Check out AOL keyword X? at the end of them. Further still, browsers became the killer app, since you could use various plugins, or sites that were JavaScript heavy, to do things without downloading or installing anything. Even this trend seems to have passed by and the ?social portal? seems to be the next killer app. Facebook has held the lead on this one for a while now, but there are a good number of clones or similar type websites that will allow folks to share photos, discuss common interests, play games, and easily consume your free time.

But on the edge of the social portal I think lies the next, or potentially current, killer app, the API. For those not familiar with term, API is an acronym for Application Programming Interface. In simple terms, it is a programming library that the creator of a program has opened up to allow other programmers to interact with the core of the system, or the data within it. For example, in the process of updating the CCG Toolkit, I chose to create web services to be used as an API to view the Tournament Card Registry data. That way, anybody that knew how to consume a web service (or had a program that did so), could easily get at card data and rulings for their cards.

Firefox became immensely popular due to its plug-in interface, which was made possible by an API that allowed programmers to create nearly any kind of ?widget? that would load with Firefox and allow the end user to do more with their browser. The Flock browser took the best plug-ins it could find and integrated them natively into the browser to enhance the user?s browsing experience.

Twitter is probably the best example of leveraging the API to its advantage. By itself, Twitter is simply a protocol for displaying status updates and passing on other people?s statuses you find interesting. The interface was incredibly simplistic: a web page. You had to various searches if you wanted to check out what else was going on in the ?twitterverse.? That all changed with the release of the Twitter API. Now every programmer under the sun could create a desktop or web based application that did all the fancy searching/sorting/following that you wanted. You could create widgets on top of the Twitter API in order to display your recent status updates, or trending topics on your blog page.

The beauty of this is that Twitter developers themselves only had to focus on the infrastructure and the protocols to be used. They can then let the creativity of developers and the demand of the users dictate which applications bubble to the surface and are used. As a result there are huge amount of twitter clients out there on every platform imaginable. By doing this, usage of Twitter itself has increased without the actual developers of Twitter having to worry about aesthetics, UX, or even platforms specifics, something that has plagued desktop applications for a long time.

Facebook has an API. Various Google Apps (including Calendar and Maps) have APIs. MySpace has an API. My favorite programming site, StackOverflow, has recently released an API and is hosting a contest to see who can build the most awesomeness out of it. I could go on and on.

So while people are getting less and less tied down to a specific platform for their data and day to day interactions (I use a Windows 7 box at home, an iPod Touch while I?m out and about, and have an XP box at work), the killer app has to keep up with this. Since keeping up with the plethora of platforms out there is insane, the killer app has had to take itself one level deeper, to the core of the code itself, or the API. The new killer app is really an API on top of a framework that is going to generate users across any platform somebody is willing to write for, without troubling the original developer at all.

I guess the next question that arises, does the API need to come first for your product, or do you generate the product and use the API to seal the deal?

 
View Comments

Posted in Articles

 

Netrep Archive: Deck Studio / RONIN Installers now Available

18 May

A quick note for any of you still looking for Netrep/Deck Studio/RONIN details…

A little while back I went ahead and took down the CCG Toolkit site, since there was no more news and updated being pushed out.

I received an e-mail [thanks Tyler] looking for the latest version of Deck Studio and I realized I didn’t put the installers out on the archive page for download by anybody interested.

You can now get the Deck Studio 1.9 and RONIN 1.7.3b installers on the Netrep archive site. Just in case you’re still using Deck Studio on the side or are interested in seeing how the apps run without having to compile the code. I also tossed in some Sheep and Ojama tokens I created a LONG time ago, they were rather fun.

The site for all of this is http://dillieodigital.net/netreparchive/. Feel free to drop me a line if you have any questions.

Enjoy all!

 
View Comments

Posted in General

 
« Older Entries
 

Switch to our mobile site