Back in February of 2011, I posted a very rough alpha release of my first WP7 IRC app called dIRCa. I abandoned the project primarily due to the heavy reliance on Homebrew sockets and rewrote it from scratch using the wonderful IrcDotNet library. Not having to handle the core IRC quirks is a godsend and luckily it works rather flawlessly with 7.5+ (Mango and above).
I originally wrote a post back in 2011 to gather emails for the beta submission process but it never got published. I was also working diligently to release a competent v1.0 but my perfectionism got the best of me.
I've since release it as open source on Github. The project is abandoned so far as my HD7 phone is no longer consistently in use now that I've switched to the HTC 8x and Windows Phone 8.
The barriers to make it a Windows Phone 8/WinRT version are pretty high:
The original project received quite a bit of downloads for my first open source project (around 700 by this time) with the reason primarily being that a XAP was already built. On Github there are no releases but I look to remedy that very shortly.
The application is pretty functional but it is rather rough around the edges. For instance, when you first start it you're required to go to the settings screen as exiting initializes and starts the connections to the various networks. I intended this to be covered in a tutorial of sorts but that was something I was going to cover off last.
Install RailsInstaller from here. I use the version with Rails 3.2.
curl.exe
, libcurl.dll
and libidn-11.dll
to C:\RailsInstaller\bin
.libidn-11.dll
was necessary to include.C:\RailsInstaller
as cacert.pem
. SSL_CERT_FILE=C:\RailsInstaller\cacert.pem
. My plan is for this post to serve as an index to the upcoming posts. Unlike the ASP.NET MVC posts that fizzled (sorry), I need to chronicle these changes in the event I need to dissect them again.
Here's the collection in no particular order:
[start year]-[current year]
and this post simply explains the what and why.One thing in the FAQ that particularly bit me during the WordPress conversion was Using Non-ASCII Characters In Your Blog. Most conversion posts cover this but I'm in the habit of always having this as part of my environment just in case.
The primary reason for my approach so far was to be a close representation as possible of the WordPress site to combat 301 redirect woes. Tags will eventually disappear I think but I like the exercise of making sure they're around in full. The platform seems to support "something" so it's fun to see how far I can go with it.
In case anyone was watching, I switched the blog from a generic WordPress with a slightly customized theme to octopress. I'm using the excellent Octoflat theme with a few notable tweaks. I reintroduced the search and feed buttons as well as expanded the navigation to allow nested menus. The theme allows for nested menu elements and while 2 levels deep is highly acceptable, I happen to use 3.
I'm writing this post using the excellent MarkPad which serves all of my needs perfectly. You don't need a markdown editor, but having one with live-preview that reinforces the markdown syntax is killer. That I can insert a URL and it automatically format the document accordingly is a small but useful touch.
I plan on posting the various tweaks that make up this blog. While there aren't a ton, I think a few of the concepts are worth expanding on. I don't claim these tweaks are original by any means but I found a lot of ideas needed to be fleshed out a little more to be acceptable for my tastes. Yes, I'm anal.
I expect nothing but great things from this migration though it took roughly a month of quite a few tinker sessions to get things where I wanted it. I blame using Ruby on Windows to be a big culprit but also my n00bness got in the way in some areas. It also took me quite a bit to grok how deployments functioned but now that everything gels, I don't expect any issues.
The site will continue to be a slight work in progress as I button up some of the loose ends. I have a few design tweaks in mind and I'm looking to expand my portfolio with more current projects. Not everything I've done in the past 2 years can be seen unfortunately but there's quite a body of work piling up, waiting to be shown.
[I forgot to post this draft back in April 2010. Needless to say I no longer utilize the technique nor can really help now that it's purged from my memory]
I've cobbled together a poor-man's backup solution using PowerShell and robocopy in what I thought was a somewhat resilient solution. Robocopy turned out to be a poor choice based upon my needs and nitpicks but I wanted to outline why to save myself and others a little pain.
This URL describes the bug and relative fix: http://superuser.com/questions/48303/access-denied-error-with-robocopy-as-admin. While using /ZB and /B helps it wasn't solving the problem because the relevant ACLs weren't being created even as late as Windows 7.
robocopy has 3 (relevant) major versions: 2003 Resource Kit (the one I was using 010), Vista/RoboCopy GUI (026), and Windows 7. To make things more complicated, installing RoboCopy GUI on a 2003/XP machine will put robocopy under %windir%system32 which happens to enumerate after the 2003 Resource Kit path. This means you have to explicitly call system32robocopy or rename the resource kit version if you hope to keep the other resource kit tools.
I erroneously thought by adding users to the Backup Operators group, a requirement to use the /B switch, robocopy was creating local shadow copies. I might have been confusing it with HoboCopy and figured taking a shadow copy snapshot before a robocopy operation would fix the problem. Turns out taking all that time, determining you almost always need to be administrative, and XP's limited ability to easily expose a snapshot as a drive letter/share made this become an incredible deal breaker.
To combat the bug that started this investigation, I initially tried using version 026 of robocopy to no avail. I used every combination of /copyall, /copy:dats, /copy:dt or just /copy:d.
What really fixes the problem is to completely obliterate the destination folder(s) and start over. This would correctly build the relative ACL and prevent the access denied message but it would only be a matter of time until it happened again.
Note: Robocopy is an end-to-end solution whereas I have far more flexibility to shoot myself in the face with this PowerShell script and the Sync Framework in general.
*: This technique negates the solution completely because I'm creating these directories under the user context the script is run in.
Shadow copies aren't used so to run this in a limited user context I still need the user in the Backup Operators group. I will likely work up a solution using shadow copies on the server as I can rather painlessly manipulate them using the Create Method of the Win32_ShadowCopy Class. Sample Powershell v2 script using AlphaVSS behaves much better if you are not using Windows XP too.