I'm continuing to test the new blog engine. This evening's tests, which I'm setting up with this post, will involve some of the trickier tasks in the migration:
- Relative links to posts within the blog itself
- Links to arbitrary files using absolute paths
- Links to files with relative paths
- Links to images (like the one below) with relative paths
If you're reading this on the new blog engine, and all the links above work and the image below shows up, then the migration tool is complete. Deploying the new blog engine to production could then happen within a couple of days. Stay tuned.
I've got a development instance of the new blog engine running on Azure: http://dailyparker-dev.azurewebsites.net/. Go ahead, take a peek.
It's important to note that I'm testing the import engine right now, so the collection of entries on the development site will probably change during debugging. Also, since it's a development site, it may disappear altogether from time to time.
Plus, the master source code (from which I'm merging into my custom code base from time to time) keeps changing. And merges don't always go well. And the DasBlog instance is still in production. And so on.
At this writing, the Daily Parker has 4,992 entries going back to 1998, so it'll take a while to import them all. One of the challenges has been making sure that deep links continue to work, and images show up, so each entry has to be parsed and its internal links fixed before it can be published. And I'm doing all this outside my usual work day.
So when is go-live? No idea, but I'm shooting for November 13th.* Stay tuned.
As for the image below, it serves no purpose other than to confirm that the import tool correctly alters image tags:
* Almost nothing in that entry is still true, but it's still the anchor post of this blog.
Two things this weekend kept me from blogging. First, the amazing weather. It was warm and sunny both days, so I spent time picking apples and sitting outside with a book.
The other thing is that the time I did spend at my computer involved working on the replacement for this blog engine.
Regular blogging will continue this week.
I noted earlier that this code base I'm working with assumes all file stores look like a disk-based file system. This has forced me to do something totally ugly.
All requests for files get pre-pended with a hard-coded string somewhere in the base classes—i.e., the crap I didn't write. So when I want to use the Azure storage container "myfiles", some (but not all) requests for files will use ~/App_Data/files/myfiles (or whatever is configured) as the container name. Therefore, the Azure provider has to sniff every incoming request and remove ~/App_Data/files/ or the calls fail.
Don't even get me started on how the code assumes HttpContext.Current will exist. That has made unit testing a whole new brand of FFS.
I've been playing around with BlogEngine.NET, and I've hit a snag making it work with Microsoft Azure.
BlogEngine.NET was built to store files inside the application's own file system. So if you install the engine in, say, c:\inetpub\wwwroot\blogEngine, by default the files will be in ~/App_Data/files, which maps to c:\inetpub\wwwroot\blogEngine\App_Data\files. All of the file-handling code, even the abstractions, assume that your files will have some kind of file name that looks like that.
You must never store files locally in an Azure cloud service, because at any moment your virtual machine could blow up and be reconstituted from its image. Boom. There go your files.
You really want to use Azure storage. In its purest form, Azure storage organizes files in containers. A container can't have sub-containers. You access a container by its name only; paths are meaningless.
But because BlogEngine.NET assumes that all file stores use path names (which even works for the database file store plug-in, for reasons I don't want to go into), creating an Azure Storage provider for this thing has been really annoying. I've even had to modify some of the core files because I discovered that it applied a default path to any file request no matter what storage provider you used.
Don't even get me started on the bit of BlogEngine.NET's architecture that pulls all files around through the UI instead of allowing them to live in a CDN...
I just Googled a problem I'm having setting up a continuous-integration build, because I've had this problem before and wanted to review how I solved it before. Google took me to my own blog on the second hit. (The first hit was the entry I cross-posted on my old employer's blog.)
Why even bother with my own memory?
After struggling for almost two weeks to learn AngularJS and other technologies, I've gotten BlogEngine.NET (which will replace DasBlog as the Daily Parker's platform) to do geography and time zones the way I want them. (Notice the time stamp and globe icon at the bottom of this post.) Specifically, last night I got the clickable Google Map on the Edit Post page to work.
Sometimes I like learning new technology. This was a lot less painful than some I've taken up, with only a couple of blind alleys and a reasonable learning curve. I'm excited that The Daily Parker could migrate to its new home in just a few weeks, if I continue to make progress.
I'm still doing some R&D with BlogEngine.NET, and I keep finding strange behaviors. This is, of course, part of the fun of open-source software: with many contributors, you get many coding styles. You also don't get a lot of consistency without a single over-mind at the top.
My latest head scratch was about how labels work. I won't go into too many details, except to say, re-saving a code file with no changes in it shouldn't change the behavior of the code file. I'm still puzzling that out.
In any event, it's possible that I may have a stable-enough build with all of the features I want ready in a couple of weeks.
Of course, there's this little matter of 4,941 posts to migrate... That should be fun.
Since development of DasBlog petered out in 2012, and since I have an entire (size A1) Azure VM dedicated solely to hosting The Daily Parker, I've been looking for a new blog engine for this blog.
The requirements are pretty broad:
- Written in .NET
- Open source or source code available for download
- Can use SQL Server as a data source (instead of the local file system, like DasBlog)
- Can deploy to an Azure Web App (to get it off the VM)
- Still in active development
- Modern appearance and user experience
See? Look-and-feel is in there somewhere. But mainly I want something I can play with.
I'm still evaluating them. This list was really helpful, and pointed me towards the successor to DasBlog, BlogEngine.NET. Mads Kristensen's newest blog engine, MiniBlog, has potential, but it doesn't seem ready for prime time yet.
The changes will come at some point in the next few months, assuming I have time to play with some options and modify the chosen engine to support a few features I want, like time zone support and location tagging. I also want to see about adding completely new features, like Google Timeline integration, or private journals and events, which require encryption and other security measures that blog engines don't usually have. Not to mention the possibility of using DocumentDB as a data source...
Stay tuned. The Daily Parker's 10th birthday is coming in November.
My friend Sara, who has a Ph.D. in psychology, wrote in her blog today about dreaming's influence on inspiration, and incidentally why psychoanalysis isn't science:
REM (dream) sleep specifically is associated with increased abstract reasoning as well as increasing the strength of normally weak associations in the brain (see here). What that means is, two different things that your waking brain might not even see a connection between could become associated rather easily in a dream. Our brain does this kind of linking (neural networking) naturally, and it's a great way to learn new things - by connecting new knowledge you need to memorize to something you already know. Just as you can connect any actor to Kevin Bacon, you can connect any concept in your brain to another. Some connections are more direct than others.
Of course, Freud and other psychoanalytic theorists would state that these strange juxtapositions are simply your subconscious trying to work out any conflicts you're having in your life. In fact, pretty much everything goes back to this idea of the subconscious, at least for psychoanalysts.
Why do we need ... theory and hypothesis if Freud's and other psychoanalysts' theories can sum much of this up, in a neat, Oedipus-complex-themed package? After all, parsimony is an important aspect of science - the simplest explanation tends to be the best one, in the absence of evidence to support one over the other.
But that's the thing - the various social psychological theories outlined above have just that: evidence. Specifically empirical evidence, which is pretty important for science, something I've also blogged about before. In fact, psychoanalytic theories lack the basic ingredients that make them at all scientific: the ability to test these concepts (we call this 'testability') and, if they are false, demonstrate that (we call this 'falsifiability'). If there really are subconscious forces operating in your brain, trying to give you glimpses of what's really bothering you (latent content) but hiding behind symbolism (manifest content), how would we even begin to test this? After all, they're subconscious. But for social psychological theories, such as priming, we may know what evidence we would observe if priming happened and what we would observe if it isn't happening.
You can read Sara's other thoughts on psychology and horror movies at Deeply Trivial.