Brian Chavez - Entrepreneur & Computer Engineer

Setting up latest Redis on Ubuntu

• add-apt-repository ppa:rwky/redis
• apt-get update
• apt-get install redis
• nano /etc/redis/redis.conf
• service redis-server restart

Extra: Ensure Durable Redis

(make Redis durable on every dataset change)

• nano /etc/redis/redis.conf
• Comment out:
  # save 900 1
  # save 300 10
  # save 60 10000
• Change:
  appendonly yes
  appendfsync always
• Ensure:
  no-appendfsync-on-rewrite no
  auto-aof-rewrite-percentage 100
  auto-aof-rewrite-min-size 64mb

Cleanup: delete /var/lib/redis/dump.rdb since we're not using snapshots.

The AOF file is in /var/lib/redis/appendonly.aof; this is your dataset on disk.

Log files are in /var/log/redis/redis.log

Hope that helps,
Brian Chavez

Be sure to check our $TERM variable.

cowboy@bigcowboy:~$ echo $TERM
xterm-256color

It should have the words "256color" before you can use httpie's --styles.

Specifically, the offending code is in httpie models.py: Line 25

colors = 256 if '256color' in os.environ.get('TERM', '') else 88

Hope that helps,
Brian Chavez

I tried loading rpi-pwm on my Raspberry Pi, but ran into some issues. After some tinkering I was able to compile rpi-pwm.c on the Raspberry Pi, but I kept running into Invalid Format issues anytime I tried to insmod rpi-pwm.ko which had the following dmesg:

rpi_pwm: disagrees about version of symbol module_layout

I guess this generally means I need to compile my module in the same way the kernel is compiled on the Raspberry Pi. Otherwise, the kernel will reject the module.

I've found that cross-compiling works best. This means, building your kernel and modules on a different platform rather than on the Raspberry Pi hardware directly. I did NOT have any luck compiling my kernel module directly on Raspberry Pi hardware.

In detail, first you'll want to cross-compile the Raspberry Pi Linux kernel so it builds Module.symvars and other intermediates. You won't actually use the kernel that is being cross-compiled, just the intermediates to compile your module. Next, you'll cross-compile your module using those intermediates. Once your module is cross-compiled, copy the .ko module to your running Raspberry Pi and you should be able to load it along with the stock kernel. The following is a quick how-to cross-compile the Raspberry Pi Kernel modules on Ubuntu 12.04:

First, know what version of RPi you're running:

uname -r and uname -a

root@raspberrypi:/# uname -r
3.2.27+
root@raspberrypi:/# uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux

I've downloaded everything into a directory called ~/rpi on my Ubuntu machine.

1. Compile the Kernel

For 3.2.27+:

(instructions generally flow from: http://elinux.org/RPi_Kernel_Compilation)

• Install Ubuntu
• Get the rpi-3.2.27.tar.gz tarball
• Get the tools tarball
• tar xzf rpi-3.2.27.tar.gz and tar xzf master.tar.gz (tools)
• Set the environment variable CCPREFIX:
  export CCPREFIX=
  /home/cowboy/rpi/tools-master/arm-bcm2708/arm-bcm2708-linux-gnueabi/bin/arm-bcm2708-linux-gnueabi-
• Set the environment variable KERNEL_SRC:
  export KERNEL_SRC=/home/cowboy/rpi/linux-rpi-3.2.27
• In KERNEL_SRC: execute "make mrproper" to ensure you have a clean kernel source tree.
• Pull /proc/config.gz from your running Raspberry Pi and extract it into KERNEL_SRC on your Ubuntu machine.
  
  scp pi@rpiaddress:/proc/config.gz ./ (transfers it to Ubuntu)
  zcat config.gz > .config (uncompresses .config)
  mv .config $KERNEL_SRC (moves the uncompressed .config to KERNEL_SRC) 
  
  
• On Ubuntu: Prime kernel with the old config:
  make ARCH=arm CROSS_COMPILE=${CCPREFIX} oldconfig
• On Ubuntu: Build the kernel:
  make ARCH=arm CROSS_COMPILE=${CCPREFIX}

This will produce a fresh Module.symvers and since you're using the cross-compile tools, the intermediates the tools generate should be binaurally compatible with Raspberry Pi.

2. Compile your kernel module

Next, make a separate directory outside of KERNEL_SRC (or example: ~/pwm) and write a quick Makefile for your kernel module:

obj-m += rpi-pwm.o

all:
    make ARCH=arm CROSS_COMPILE=${CCPREFIX} -C /home/cowboy/rpi/linux-rpi-3.2.27 M=$(PWD) modules

clean:
    make -C /home/cowboy/rpi/linux-rpi-3.2.27 M=$(PWD) clean

(learn more about compiling Linux kernel modules here)

When you're ready to compile your module, go ahead and execute "make" and you should be gold. Copy your rpi-pwm.ko to your RPI then use modinfo rpi-pwm.ko to review the module information:

root@raspberrypi:/# modinfo rpi-pwm.ko
filename:       /home/pi/temp/rpi-pwm.ko
alias:          platform:bcm2708_pwm
author:         Sean Cross <xobs@xoblo.gs> for Adafruit Industries <www.adafruit.com>
license:        GPL
srcversion:     44D62553C321E91B0CB1996
depends:       
vermagic:       3.2.27 preempt mod_unload modversions ARMv6

Last but not least, you should be able to insmod rpi-pwm.ko without any problems. My dmesg:

root@raspberrypi:/# dmesg | tail -5
[18852.504621] rpi_pwm: disagrees about version of symbol module_layout
[19043.461377] rpi_pwm: disagrees about version of symbol module_layout
[21401.160720] rpi_pwm: disagrees about version of symbol module_layout
[22026.927225] rpi_pwm: disagrees about version of symbol module_layout
[26733.475758] Adafruit Industries' Raspberry Pi PWM driver v1.0

If you want your module to auto start:

• Copy your .ko module to /lib/modules/3.2.27+
• Edit /etc/modules and append your module to the end of the list.
  Mine looks like:

  # /etc/modules: kernel modules to load at boot time.
  #
  # This file contains the names of kernel modules that should be loaded
  # at boot time, one per line. Lines beginning with "#" are ignored.
  # Parameters can be specified after the module name.

  snd-bcm2835
  spi-bcm2708
  i2c-bcm2708
  i2c-dev
  rpi-pwm

• Next, run: depmod -a
• Next, run: modprobe <yourmodulename>

Then reboot and your module should auto start on boot.

Hope that helps!
Brian Chavez

Page Inspector causing multiple calls to HttpApplication : Application_Start in Web Site Projects

I had a mysterious problem receiving multiple calls to Application_Start on almost every HTTP request to IISExpress. Upon further investigation, I found Visual Studio 2012's Page Inspector causing the problem.

Inside the default machine's Web.config located at: Windows\Microsoft.NET\Framework\v4.0.30319\Config, XPath: \System.Web\compilation\assemblies has an assembly "Microsoft.VisualStudio.Web.PageInspector.Loader", which dynamically loads itself via [assembly: PreApplicationStartmethod(typeof(RuntimeLoader),"PreApplicationStart"] attribute.

The ASP.NET BuildManager's hash of the compiled web site project kept changing upon the first & subsequent request to IISExpress. Somehow the dynamically loaded PageInsepctor.Runtime caused the HttpApplication to shutdown, startup, in an oscillating fashion (hence, the mulitiple Application_Start calls) as requests were being processed. Specifically, Microsoft.VisualStudio.Web.PageInspector.Runtime.Tracing.
    SelectionMappingExecutionListenerModule.PreApplicationStart()'s call to BuildManager.AddCompilationDependency() caused root compilation hash to change.

Disabling and removing Microsoft's Page Inspector feature removed the restarting interference. Here's how to remove the entire feature from your project:

Disable Visual Studio 2012 Page Inspector

To disable visual studio Page Inspector remove the assembly inside your Web.config located in configuration/compilation/assemblies:

Alternatively, you can add this to your appSettings:

Hope that helps,
Brian Chavez

UPDATE: 9/7/2012 - An "official" theme editor for VS2012 is now available in the VS extension gallery available here:
http://visualstudiogallery.msdn.microsoft.com/366ad100-0003-4c9a-81a8-337d4e7ace05
The remainder of this post is for archival purposes and is out-dated.

So, Visual Studio 2012 is nice but I ran into some serious usability issues. I like the dark theme, but it was too dark. Something between light and dark would have been perfect.

In my current setup:

• I turn down my monitor's contrast to the lowest setting.
• I turn down my Nvidia driver contrast down to the lowest setting.

I spend a lot of time on the computer so it is important to  keep these settings where they are. I don't want fiddle with these nobs back and forth just to use Visual Studio.

After some research and play, I found where Visual Studio 2012 was storing and reading theme / color data. Specifically here:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0_Config\Themes

Notice, there's a Data value in each sub-key category. This Data value is binary-byte packed with color values and color names. I wrote a small tool that that reads Data for each category and allows you to inject your own colors.

 

Visual Studio 2012 Theme Editor

Play it safe: Please backup your registry before using this. You can backup your current theme by using the green "Backup Theme to File" button.

• Download here
• Source code here
  

Visual Studio 2012 Themes

• Midnight Theme - by Eugen Podsypalnikov
  
  
  
  
• Visual Studio 2012 in 2010 Colors - by Cihan Yakar
  
  
  
  
• "Cool Blue" theme by ~T~A~B~
  
  

Visual Studio 2012 Icon Patcher

• Change Visual Studio 2012 Icons
  
  
  

FAQ

• Can I change the ALL CAPS menu?
  Yes,
     1. Close Visual Studio
     2. Launch regedit and navigate to
       HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General 
     3. Create a DWORD value named SuppressUppercaseConversion with value 1.
  That should suppress the upper casing on the FILE, EDIT, VIEW menu area in Visual Studio 2012.
• Can I change the Visual Studio 2012 Icons?
  Yes, See the link above: http://vsip.codeplex.com/
• I changed a color, it doesn't work. What's wrong?
  Keep trying. There's hundreds of colors VS uses so it might take some time to find the color you're trying to modify. Most of Visual Studio's Shell colors are in the Environment category - take a look in there. Also, keep in mind, Visual Studio uses many colors, and sometimes colors get "brushed over" others.
• How do I reset my theme?
  Click on the Reset Theme link in the main program to go back to stock colors.
• There's a bug in your program. Can you fix it?
  Probably. I didn't spend much time creating a bulletproof UI. I just needed something quick to hack these color values. Since it's open-source, feel free to fork, download, fix, and push me a patch.
   

For me, some important colors that I needed to adjust:

• Environment > CommandBarMenuBorder
• Environment > CommandBarMenuBackgroundGradient(Start/End)
• Environment > CommandBarMenuItemMouseOver

 

Hope that helps, happy coding! 
Brian Chavez

This is primarily used as notes for me …

As the title suggests, I had a problem with *some* DLL references inside Project.Web\Bin\*.refresh files not being copied during the .wdproj build process.

There were a few blogs out there that offered some solutions like editing the Microsoft.WebDeployment.targets file and removing the Copy “Condition” inside _ResolveReferences target (Line 862). But these solutions bothered me because it did not explain the root cause of the problem.

What was most strange about this problem was that all my builds worked before, so something must have goofed up the build process.

It turns out, your .wdproj file may be out-of-sync with your .SLN file. Double check the following XML elements inside your .wdproj file:

• <SourceWebPhysicalPath> -- You need to triple check that this path is correct,
• <SourceWebProject>GUID|ProjectURL/Name</SourceWebProject> -- The GUID in the <SourceWebProject> XML element must match the web-project GUID in your .SLN file. Also, the ProjectURL/Name should also match the string that follows the web-project GUID in your .SLN file too.

It turns out, if you were using Visual Studio’s built-in Cassini web server, then switched to IIS Express at a later date, your .wdproj may contain stale reference information located in the two XML tags listed above. Specifically, the format of the <SourceWebProject> tag using Cassini is “GUID|ProjectPath”, and “GUID|ProjectURL” for IIS Express. When you convert a website from Cassini to IIS Express, the website’s GUID changes and ProjectPath becomes ProjectURL in the .wdproj. The website GUID and ProjectURL values can be found inside the .SLN file after the change has been made.

If you’re unsure of what GUID|ProjectURL values are needed, simply remove the .wdproj deployment project from solution and add it again (overwriting your previous .wdproj), and Visual Studio will recreate the necessary values inside your .wdproj. Just remember to refresh your .wdproj when switching between IIS Express and Cassini.

Additional Tip 1

Double check your .SLN “E24C65DC-7377-472B-9ABA-BC803B73C61A” (Website Projects) sections of your .SLN file and ensure the AspNetCompiler.PhysicalPaths are correct.

Additional Tip 2

Make sure your website project is set to “build” in the Configuration Manager for your Release configuration.

  

This is important because, during the build process, MSBuild creates “meta projects” (.metaproj) for your website projects that are derived from your .SLN file. The reasoning is, website projects (which differ from Web Application projects) do not have an accompanying “.csproj” project file (which are essentially MSBuild scripts). Project settings for website projects are stored in the .SLN file and the .SLN file is used to create an intermediate (.metaproj) MSBuild script on-the-fly. You never see the resultant intermediate build script emitted from MSBuild by default.

To see the intermediate build script for your website project:

• set MSBuildEmitSolution=1
  (via command-line - environment variable)
  
• msbuild MyProject.sln /property:Configuration=Release /target:Rebuild
  (run MSBuild on your solution)

If your website project is set to build in Release configuration as shown in the pictures above, you should see a few files similarly named “localhost.metaproj” and “MyProject.sln.metaproj” emitted from MSBuild as it transformed your website project settings into intermediate MSBuild scripts. The “localhost.metaproj” files contain MSBuild tasks that read .refresh files and copy .refresh references into your Project.Web\Bin folder.

Ultimately, this will ensure all .refresh files are honored & copied before your .wdproj deployment build script executes.

Additional Tip 3

Ensure your website project and .wdproj has the correct build order in your solution:

Your .wdproj should be somewhat last and definitely after your website project build.

Additional Tip 4

If you want to avoid the extra aspnet_compile from enabling the “build” in tip 2 and you really feel up for modifying your Microsoft.WebDeployment.targets file, simply remove the ! operator from the Copy Condition in:

Removing the ! from the Copy Condition will copy the DLL references into your Web\Bin directory and all should be well.

Hope that helps,
Brian Chavez

Finished writing a C# / .NET implementation of the Dwolla Off-Site Gateway API released under the LGPL.

Code is available on github.

Patches, improvements, suggestions welcome.

Thanks,
Brian Chavez

Recently, Visual Studio 2010 was taking ridiculously long time saving settings from the following locations:

• Tools > Options… window.
• Tools > Import and Export settings … window

Saving settings from these location took about 15 minutes to save! It was seriously frustrating.

I noticed, CurrentSettings.vssettings file was approaching 13MB.

After opening the CurrentSettings.vssettings file I found multiple <ViewBookmark> tags filling up the settings file. They looked something like:

<ViewBookmark Name="D:0:0:{GUID}|… path to file .css …||{GUID}" ViewBookmarkType="DocumentWell" DockedHeight="1399" DockedWidth="1342.97336877197"/>

So, I manually deleted the duplicate lines in the CurrentSettings.vssettings file. The CurrentSettings.vssettings file was reduced to 335KB. Awesome. I opened and closed Visual Studio to see if the settings file still worked and to my surprise, the bloated lines I removed were automatically inserted back into CurrentSettings.vssettings! Wow. Seriously?

After some time tracking down where these lines were coming from, it turns out if you look in the following folder:

C:\Users\USER\AppData\Roaming\Microsoft\VisualStudio\10.0

You’ll find two files “Debug.*.winprf” and “Design.*.winprf” and associated *.winprf_backup files. These files appear to be WPF XAML files that store Visual Studio’s window (and toolwindow) information. If you delete them, Visual Studio will re-create the XAML files using default tool window locations. However, if you want to keep your window settings, you’ll need to manually edit the files and remove the bloated lines that are filling up the XMAL file.

Once you remove the bloated XMAL lines from your *.winprf and CurrentSettings.vssettings file, saving your Visual Studio settings should be quick once again!

Hope that helps,
Brian Chavez

The Problem

I like using RDP but I get very frustrated when the terminal window doesn’t remember the location.

Evert time I connect via RDP, the remote window starts in the top-left corner of my primary screen. It drives me nuts.

In this post, I’ll explain how to save the location of the window without hacking RDP files.

 

Set The Defaults

Run MSTSC:

 

Next, adjust your desired settings in General, Display, and Local Resources….

 

 

Click Save button, DO NOT CONNECT, and Close MSTSC when done.

Essentially, what we’ve done is save these connection preferences to “Default.RDP” (see details at the end of this post).

 

Place The Window

Next connect to the machine using the /v: switch:

 

Move, place, resize, and adjust the terminal window where you want MSTSC to start every time.

NOTE: If you want scrollbars to be removed adjust the height and width of the window now. You may need to click the restore button between the close and minimize button on the top right.

 

Next, Close the terminal window when you’re done and click OK.

MSTSC should now save the last position of the window in “Default.RDP” (see details at the end of this post).

 

Save The RDP file

Run MSTSC again:

Now Click SAVE AS..:

Double click on your new RDP file.

Your new terminal window should start  at the same position every time you double click on your new RDP file.

 

The Details: The Default Settings File

MSTSC stores default connection preferences in a hidden file called “Default.rdp” located in:

[System.Environment]::GetFolderPath([Environment+SpecialFolder]::MyDocuments)

# Windows 7: %USERPROFILE%\Documents\Default.rdp

# Windows 2000 / XP: %USERPROFILE%\My Documents

Note: If you don’t see Default.rdp, you’ll need to turn on “Show Hidden Files”.

Default.rdp is the default settings (& window state location) for MSTSC.

Brian Chavez

Gee, setting up an SNTP/NTP server in Windows is not intuitive.

The good news is: When configured correctly, you can use the Windows Time (W32Time) service as an SNTP/NTP server for both windows and non-windows SNTP/NTP clients.

Here's how to do it:

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry entry:

   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\

3. In the right pane, right-click AnnounceFlags, and then click Modify.
4. In the Edit DWORD Value dialog box, under Value data, type 5, and then click OK.
5. Enable NTPServer.
   1. Locate and then click the following registry subkey:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
                                                      Services\W32Time\TimeProviders\NtpServer\

   2. In the right pane, right-click Enabled, and then click Modify.
   3. In the Edit DWORD Value dialog box, type 1 under Value data, and then click OK.
6. Exit Registry Editor.
7. At the command prompt, type the following command to restart the Windows Time service, and then press ENTER:

   net stop w32time && net start w32time

This should get you setup with minimal registry hack impact.

Tips

• Make sure W32Time is set to Automatic startup mode.
• Make sure UDP 123 is allowed through your firewall.
• Use this InternetTime program to help you debug connectivity to your SNTP/NTP server.
  internettime.zip

Hope that helps,
Brian Chavez