Spokane People – An Open Forum for Spokane’s Neighborhoods To Use

Spokane People

For anyone who is interested, I have put together a bulletin board called “Spokane People”, and I welcome everyone in Spokane to use it as an open forum to post whatever you would like to that involves your neighborhood. I have added a section for each neighborhood in Spokane, so everyone can have their own area to use. 100% free, and less restrictive than other social media platforms. You could think of it as a hybrid between Facebook, NextDoor, and CraigsList, with a clean design that looks as good on a computer as it does a smartphone. There’s also sections specifically for Buy/Sell/Trade/ISO posts, Free Business Listings, and Upcoming Community Events. Check it out at https://spokane.booksnbytes.net/

Migrating From visualstudio.com TFS to an In-House TFS Server (With Full History)

For the past two years, I have been actively developing a collection of proprietary software products, which I have maintained in one of Microsoft’s free visualstudio.com TFS repositories. For a single developer, this has been a great way to keep a complete revision history on the code base. Recently, I ran into a few caveats that have put me in a situation where it is time for the repository to be moved to a newly-created in-house Team Foundation Server. Thinking to myself “ok, I’ll just migrate the repository real quick”, I set to work. After a few hours of poking around VSO, it became painfully clear that there is no viable way to do this (while keeping the full revision history), since I did not have access to the underlying database for the repository. This gave me two options: 1.) Checkout the latest copy of the repository and commit it to the new repository (keep the latest source but lose the history), or 2.) Write some script that will loop through the repository, checking out each and every revision (starting at 1), and committing them one-by-one to the new repository (keep the source and the history, but may take DAYS or WEEKS to run).

After thinking on the options, I realized that they both sucked. I then remembered that I had written an article awhile back about Migrating from TFS to Git, so I pulled it up, re-read it, and though “I wonder if I can use this same technique to do a TFS to TFS migration?” The answer was yes! Though there was one downside: I kept all of the revision history, but I lost the Changeset Timestamps (all of the migrated history has the same check-in date). In the same fashion of migrating from TFS to Git, I had to use the “git-tf” tool for this process. Here’s how I did it:

1. Installing Git-TF

Download and install the Git-TF utility from the CodePlex page here, and extract it somewhere on your computer. Don’t forget to install the Java Runtime Environment (JRE) if you don’t already have it, it is required for the tool to run.

2. Cloning the TFS repository (with full history)

The next step was a bit trickier. The tool needs the latest copy of the TFS repository that is going to be migrated. However, to clone the repository, I needed to configure Alternate Credentials on my visualstudio.com account. It took a while to find a recent enough article on how to do this. After some trial and error, it’s easier than it should be:

  • Log into your visualstudio.com account
  • In the top-right corner, click on your name and select Security
  • In the new window, click on “Alternate authentication credentials” on the left
  • Make sure the “Enable alternate authentication credentials” checkbox is checked
  • Enter a secondary username and password to use, and click save

Once this was done, it was just one command from a Command Prompt to clone my TFS repo:

git-tf.cmd clone https://jarrenlong.visualstudio.com/DefaultCollection $/RepoIAmMoving –deep

Note: If you didn’t follow the Git-TF instructions and add the Git-TF root directory to your system path, just use the full path to the git-tf.cmd file when executing the command. Since I only planned on using this tool once, this is what I did.

This did take a while to clone, as it is pulling the entire TFS repo history with it. Just let it cook until it’s done. The repository that I was migrating had just over 4900 Changesets, so it ended up taking about 24 hours to do the complete clone. While this is running, it will be a good time to go ahead and create an empty TFS repository on your new server, if you haven’t already done so. For this example, we’ll say that my new Team Foundation Server is accessible at https://tfs.mynewserver.com/DefaultCollection, and the repo I created is called “RepoIAmHosting”.

3. Performing the TFS to TFS Migration

Before you commit the repository to the new server, you need to make a few minor changes:

  • Using Windows Explorer, you need to open the .git directory that was created inside of the cloned repo. There should be a file in there named “git-tf”; rename it to something else. This file tracks all of the Changesets for the repo, but is bound to the old server. If you tried to commit the repo to the new server now, you will most likely get a “Changeset XXX not found” error.
  • Use a text editor to modify the “config” file in the .git directory. This file tells git where the server for the repository is located. In here, you need to modify the [git-tf “server”] section to point to the new server/repository.

For this example, I would change

[git-tf “server”]
collection = https://jarrenlong.visualstudio.com/DefaultCollection
serverpath = $/RepoIAmMoving

To

[git-tf “server”]
collection = https://tfs.mynewserver.com/DefaultCollection
serverpath = $/RepoIAmHosting

Save and close the config file. You are now ready for the actual commit! From the root directory of the repository you cloned, you just need to issue a “git-tf.cmd checkin –deep” command, which will start committing the complete repository to the new server. Again, this is going to take a while, but when the check-in is finished, you will have your complete repository history visible in the new TFS portal. Note: If you need to retain commit usernames, use the –keep-authors flag with this command (see git-tf documentation for info on how this works). In my scenario, I was the only developer on the project, so there was no need for me to do this.

As I said at the beginning of this article, there is only one downfall to this process, which is that each and every Changeset will have the same timestamp (+/- a few minutes). Sadly, this appears to be unavoidable (at least, I have not found a way to preserve the commit timestamps). There is one way that you can (partially) retain the timestamps though. By using the –metadata flag with the checkin command, git-tf will attach the additional metadata for each commit from the old repository. This will preserve the timestamps, however it makes the display of each commit look a little funky in the Changeset list for the repo when viewed from the web portal. Instead of showing the Changeset # and the description attached to the commit, the web portal will just show “Commit xyz (Timestamp)”, and the description of the commit will be embedded further inside of the Changeset’s details.

Like this article? Make a Donation to Feed the Developer!

Stellaris LaunchPad Composite Video Line Multiplexer

After five days of next to non-stop school and work (sleep? what’s that?), I’ve decided to take a few hours for myself to relax and do some R&D on my first Stellaris LaunchPad project, a USB Composite Video Line Multiplexer. For the less than geeky out there, you can think of this as a KVM switch for RCA video devices (remember the Red, White, Yellow cables that used to go into the back of your Standard Definition TV? They’re still pretty popular…). Why would I want to revive a dying technology using cutting-edge hardware? Simple: I was robbed for the 5th (count them: 1, 2, 3, 4, 5) time since moving into my house (just shy of 8 months ago). Argh!!! Naturally, my response to this rash of repeat crime was to (call the Spokane Police Dept? Nah, I’d rather not get shot) stop by my local hardware store and pickup an array of security lights, cameras, and motion sensors/alarms. Two hours and $200 later, any motion within 50′ of my house will light up an entire city block (all non-drug addicted neighbors cleared it, said they didn’t mind waking up to summer-time daylight at 2AM in November, awesome people), sound an alarm, and immediately target the motion source using two mechanized 5.56mm SARs (of my own design) with rubber rounds (overkill? No kill, they’re rubber…Excessive show of force? Maybe… ).

Impressive security system for cheap? Very much so. 🙂 Back on topic: After installing my new system, I realized I had one major problem: The cameras I picked up both stream NTSC (black & white) video and single-channel audio over Yellow/White RCA cables. No problem. My (borrowed) TV only has one RCA input. BIG PROBLEM!!! How am I supposed to monitor two security cameras, let alone record the A/V they capture with only one RCA input?

  • Idea #1: Just unplug one camera and plug the other in. Results: Horrible idea, pain in the ass, and the cables are cheap and already getting loose after a few connections.
  • Idea #2: Get a TV/VCR/DVR with 2+ RCA inputs. Results: I managed to carry my ancient 32″ RCA CRT TV up two very narrow flights of stairs, only to find out that it takes ~45 seconds to fully switch from Line 1 to Line 2. Better, but still a pretty big delay, and I can still only record one line at a time using the built-in VCR.
  • Idea #3: Go drop a few grand on a real security system. Nope. Won’t do it.
  • Idea #4: Wait! I’m an engineer! DIY multiplexer to the rescue!

So, what  is a multiplexer? From Wikipedia: In electronics, a multiplexer (or MUX) is a device that selects one of several analog or digital input signals and forwards the selected input into a single line. To simplify: A MUX allows you to have multiple input lines, and then select which one will be forwarded to the output line. In this sense, your typical bathroom sink is a MUX, allowing you to select whether you want hot or cold water. Awesome, this is (a fraction of) exactly what I need!

To refine the idea further, this device will need to be able to:

  1. Sample video data from one or more RCA inputs (using the cameras for a live feed).
  2. Convert the video data received from each input into a suitable digital format for MUXing
  3. Pass the digital input data into froom each input line into the MUXer to create a single video image
  4. Forward the final video image  out the device via USB to a PC/Laptop for monitoring/recording.

Now that I’ve refined the project goals (to some extent), it’s time to get crackin’ on the fun part, building it! While I’m probably a week ahead of these posts on the project, I will leak this one picture of the first input line wiring breadboard (untested, who knows if it actually works or not, much more to do before the power gets turned on):

Next article: A brief overview of the RS-170A (NTSC) video protocol, and hopefully a working demo of NTSC video decoding using the Stallaris LaunchPad!

Like this article? Feed the developer, every dollar counts: 

Stellaris Project: Composite to USB Video Line Multiplexer

After five days of next to non-stop school and work (sleep? what’s that?), I’ve decided to take a few hours for myself to relax and do some R&D on my first Stellaris LaunchPad project, a USB Composite Video Line Multiplexer. For the less than geeky out there, you can think of this as a KVM switch for RCA video devices (remember the Red, White, Yellow cables that used to go into the back of your Standard Definition TV? They’re still pretty popular…). Why would I want to revive a dying technology using cutting-edge hardware? Simple: I was robbed for the 5th (count them: 1, 2, 3, 4, 5) time since moving into my house (just shy of 8 months ago). Argh!!! Naturally, my response to this rash of repeat crime was to (call the Spokane Police Dept? Nah, I’d rather not get shot) stop by my local hardware store and pickup an array of security lights, cameras, and motion sensors/alarms. Two hours and $200 later, any motion within 50′ of my house will light up an entire city block (all non-drug addicted neighbors cleared it, said they didn’t mind waking up to summer-time daylight at 2AM in November, awesome people), sound an alarm, and immediately target the motion source using two mechanized 5.56mm SARs (of my own design) with rubber rounds (overkill? No kill, they’re rubber…Excessive show of force? Maybe…).

Impressive security system for cheap? Very much so. Back on topic: After installing my new system, I realized I had one major problem: The cameras I picked up both stream NTSC (black & white) video and single-channel audio over Yellow/White RCA cables. No problem. My (borrowed) TV only has one RCA input. BIG PROBLEM!!! How am I supposed to monitor two security cameras, let alone record the A/V they capture with only one RCA input?

  • Idea #1: Just unplug one camera and plug the other in. Results: Horrible idea, pain in the ass, and the cables are cheap and already getting loose after a few connections.
  • Idea #2: Get a TV/VCR/DVR with 2+ RCA inputs. Results: I managed to carry my ancient 32″ RCA CRT TV up two very narrow flights of stairs, only to find out that it takes ~45 seconds to fully switch from Line 1 to Line 2. Better, but still a pretty big delay, and I can still only record one line at a time using the built-in VCR.
  • Idea #3: Go drop a few grand on a real security system. Nope. Won’t do it.
  • Idea #4: Wait! I’m an engineer! DIY multiplexer to the rescue!

So, what  is a multiplexer? From Wikipedia: In electronics, a multiplexer (or MUX) is a device that selects one of several analog or digital input signals and forwards the selected input into a single line. To simplify: A MUX allows you to have multiple input lines, and then select which one will be forwarded to the output line. In this sense, your typical bathroom sink is a MUX, allowing you to select whether you want hot or cold water. Awesome, this is (a fraction of) exactly what I need!

To refine the idea further, this device will need to be able to:

  1. Sample video data from one or more RCA inputs (using the cameras for a live feed).
  2. Convert the video data received from each input into a suitable digital format for MUXing
  3. Pass the digital input data into from each input line into the MUXer to create a single video image
  4. Forward the final video image  out the device via USB to a PC/Laptop for monitoring/recording.

Now that I’ve refined the project goals (to some extent), it’s time to get crackin’ on the fun part, building it! While I’m probably a week ahead of these posts on the project, I will leak this one picture of the first input line wiring breadboard (untested, who knows if it actually works or not, much more to do before the power gets turned on):

Next article: A brief overview of the RS-170A (NTSC) video protocol, and hopefully a working demo of NTSC video decoding using the Stallaris LaunchPad!

Like this article? Feed the developer, every dollar counts: 

Unpacking the TI Stellaris LaunchPad

Alright, my first post on the temp site while I abandon ship from GoDaddy! Got home tonight to find that my newest microcontroller development kit came in the mail today! For $9.98, I received two brand new TI Stellaris LaunchPad Evaluation boards, preloaded with the Texas Instruments LM4F120 Series of ARM Cortex-M4 processor. This little beast cranks out 80MHz of 32-bit goodness. With a built-in FPU, this little baby is well suited for any application where calculation and accuracy are key (industrial, automotive, etc.). It also features 256KB of single-cycle 40MHz Flash/32KB SRAM/2KB EEPROM, and built-in USB debugging and JTAG support out of the box.

Speaking of out of the box, behold!

1113122320 1113122321 1113122322b

After reading through the welcome booklet, it was time to plug the eval kit and try out the demo program that comes with it. After switching the device to debug and plugging it into my laptop, the board flashed green, and then started cycling through the colors of the spectrum. Pressing the SW1 and SW2 buttons let me cycle through the colors manually, just to let me know the buttons work 🙂 Right out of the box, this simple display of power is already making me ready to dig in. SDK installation in progress, more to come!

1113122345 1113122345b

Like this article? Feed the developer, every dollar counts: