January 2010 - Posts
Recently I joined the DotNetNuke Engineering team, specifically as the Director of Engineering where my primary focus will be on NEW development; that would include both new features, and enhancements to existing features and enhancements at the core level. What this means is that my team and I will be responsible for soliciting feedback from our various customers and producing feature/functional design specifications, transitioning those to technical requirements and eventually pushing those features into a future release of the product.
Side Note: Joe Brinkman will be taking on Support and Maintenance of the product moving forward. There will be a natural flow of information and events from my team into his team.
In the interest of being transparent with the community I want to open the door to the community and allow us to discuss these items openly. First and foremost I wanted to give a quick background on the development methodology and the high-level points which we my team be adopting.
Second I will cover the current progress made to date so far, within that methodology.
And finally I wanted to cover off things what YOU can do, as a community to help grow the product.
Development Methodology
Scrum
The plan, which is in its early adoption phase, is to follow the Scrum methodology. We are now just taking our first baby steps into our first official sprint within the organization.
Shaun Walker, Joe Brinkman, Charles Nurse and I have gathered to examine the complete list of items on our Product Backlog – which Shaun currently maintains, and have decided on this feature set to be delivered in the next sprint.
I recently gave a presentation to my team, and here are the high level points which the team needs to understand:
1. This process is currently limited to the Engineering / Development team
a. This, for now, excludes the product support and maintenance team
2. We hold a daily scrum at 10:00am
3. If you cannot attend physically you are required to call in (we have a VOIP based conference room setup)
4. We enforce strict penalties for tardiness ($1.00 into our beer fund, or 10 pushups)
5. The newest hire is responsible for:
a. Taking Scrum notes
b. Updating the Burn down chart
6. The ScrumMaster, for now, is me
7. The person who currently represents the Key Stakeholders is Shaun
Schedule
Some of the key dates to take note of include:
1. Scum meetings happen at 10:00am, all to attend
2. We have month long iterations, which follow the general guidelines of:
a. Day 1: Sprint Planning Meeting
b. Day 2: Task breakdown, accept work (duration is tentative)
c. Day 3 to Day 21: Development effort
d. Day 22: QA Hand off
e. Day 22 to Day 30 : QA Effort – end result is a potentially shippable product
3. Quarterly Feature Releases (Maintenance releases are monthly)
It is important to note that although we have monthly sprints, we only release quarterly. This means we are going to try to make available these interim feature builds to the community. The exact nature and plan for this is still tentative. This also allows for the sales cycle to pick and choose their build for demo’s and trade shows – fully tested and stable vs. latest and greatest feature set.
As a side note, we have officially adopted Olympic City names for our development sprint names. For the first sprint, which has already start has a code name of Vancouver. The next sprint will be named Sydney.
Our timeline of events, at a very high level is as follows:
1. 5.3 - Vancouver Sprint is due
2. 5.3 - Vancouver Beta Customer Release
3. 5.3 - Sydney Sprint is due
4. 5.3 – General public release
Planning/Tasking
In the past I have had much success in implementing the usage of Sticky notes for project tasking and tracking. What this means is that as we gather to break down each major feature set down into its various bits we keep track of each task with the help of sticky notes. On each note, we indicate the Sprint (5.3/Vancouver, etc). Which component which is being worked on, the task name (Create table to store xyz) and the approximate “size” of the task (1-4). If the task is larger than a 4, we simply break it down even further.
The goal of this is, is to get a broad picture and “size” of each deliverable and how much the team can deliver in a fixed amount of time. For example if we add up the size of all of the tasks, across the team, and it adds up to 100 and we deliver that early, then we know that next time we should consider adding more items to the Sprint Backlog (work to be delivered). If we can’t meet the deadline then we have over allocated and will need to adjust accordingly. Over time what happens is, as the team matures, the amount which we need to adjust for each sprint is reduced and we have a very predictable method for estimating how much work to take on during each Sprint.
Now that we have each of our tasks broken down and on stickies we have a large board in the office which we place of them on, under one of the following columns/categories:
1. Backlog
2. In Progress (and each person has an In-Progress column)
3. Deferred
4. QA
As each developer begins a task, and moves it along to completion they are to also move the sticky. This gives everyone a very obvious indicator of progress. Take for example the QA team; they know what features are coming in the near future and when. Shaun can take a look at the board and see the progress being made by the team.
It is very important for me to have this exist in the physical world. It needs to be out there, just like our dirty laundry. It keeps us in check and on the ball, not to mention being extremely transparent with the rest of the team.
What can you do?
If you do not already have a channel into DotNeNuke and you want to get involved drop me an email. If I can’t handle your request directly I will do my best to put you into contact with the correct person on our team! Feature requests, glaring issues that are just killing your adoption, comments/feedback on our process and methodology, or if you just want to pick my brain feel free to get in touch with me.
As some of you may remember I upgraded my Home Theatre PC to the Ubuntu/Live version of Xbox Media Center. Its a free and open source Media Center application. To get an idea of what the UI looks like, see here. Here is the current skin which I use, Confluence.
So anyways, I have been meaning to finally integrate X10 directly within XBMC in the form of a Python script, which is natively supported in XBMC. This article describes how I was able to accomplish this.
Note: Items starting with “>” can be interpreted as command line commands via SSH
Hardware
For the XBMC base setup and configuration see my previous post here. Now we need to add in the X10 components. In the past I have been a big fan of the X10 modules. What you need is a Firecracker (CM17a) module with a USB to Serial Adapter. The specific USB to Serial Adapter is pretty important, because of the Linux drivers available. Mine, which obviously works, is listed as…
Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC.
To be safe I do recommend using the same sort of device (at least the FTDI Chipset – Ubuntu seems to agree with it).
Once you have both of those simple components plug them in and allow your system to recognize the device. This may require a reboot.
To determine if it has been detected or not, you will need to SSH into your XBMC device and execute the command:
> lsusb
You should see something like...
Bus 004 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Since this is the first USB device on this rig, it is using ttyUSB0, so we must change permissions for that device via the command line:
> sudo chmod go+wr /dev/ttyUSB0
Software
Installing heyu
The software side of things is fairly easily done, with an existing tool called “heyu”.
Step by step..
1. SSH into your XBMC
2. > cd ~
3. > mkdir x10
4. > cd x10
5. > wget http://www.heyu.org/download/heyu-2.8.0.tgz
be sure to get the latest revision of heyu, I'm assuming 2.8.0 is the latest, but please do check.
6. Ensure the build-essentials are installed for your distro
> sudo apt-get update
> sudo apt-get install build-essential
7. Untar/gzip the heyu library
> tar -xvzf heyu-2.8.0.tgz
8. cd heyu-2.8.0
9. Build heyu (as documented in “INSTALL” file)
> sh ./Configure [option] (As a normal user)
> make (As a normal user)
> su (Become superuser)
> make install (As superuser) (choose 1)
> exit (Revert to normal user)
> heyu info (As a normal user, to test installation)
10. Start the heyu engine
> heyu start
11. And finally test; send firecracker (CM17A the All Off Command, for house code A)
> heyu falloff A
If that works, your now 1/2 of the way there!
The next set of steps will install the heyu engine to run at start up, by editing the rc.local file, here goes…
1. > sudo nano /etc/init.d/rc.local
2. Add the following lines:
chmod go+rw /dev/ttyUSB0
mkdir /var/tmp/heyu
chmod go+rw /var/tmp/heyu
/usr/local/bin/heyu start
(putty supports copy and paste, paste with the right mouse button)
3. Save, exit (ctl-o, ctl-x)
If for some reason you cant save the document, you probably missed the “sudo” portion of the previous command. Exit without saving, and start from Step 1 again.
4. Reboot (sudo reset)
Upon boot your XBMC installation will have the heyu engine started and ready for your commands. If you SSH back into your device and issue the commands:
> heyu fon A1
>heyu falloff A
> heyu help
will give you the full help documentation as usual
XBMC Scripting with heyu
XBMC scripting is pretty straight forward if you go down the WindowXML route. There are a decent amount of examples online, and I have attached here my sample, working code.
In the sample, if you work your way down to the path, and edit the file:
\X10\resources\skins\DefaultSkin\pal\HomeAutomation.xml
You will see the layout. Consider this XML is the main control structure and positioning that you can use.
Next edit the file:
\X10\default.py
This is the python script responsible for initializing the UI and handling the events. Scroll down to about line 80 and you will see this block of code:
1: if (controlID == 1001):
2: print "------------------executing A1 on------------------"
3: os.system('heyu fon A1')
4: elif (controlID == 1002):
5: print "------------------executing A1 off-----------------"
6: print os.system('heyu foff A1')
7: elif (controlID == 1003):
8: print "------------------executing restart-----------------"
9: print os.system('heyu restart')
10: elif (controlID == 1004):
11: print "------------------exiting-----------------"
12: self.close()
Notice that we are matching the “controlID” variable with the same control id=”1001” variable in the XML document.
As a final step, upload your edited script and XML document to your XBMC installation and give it a try.
Problems encountered so far
The heyu engine setup might need tweaking, especially when the XBMC device goes to sleep. Upon waking up it seems that I need to force the heyu restart command, and even then its not 100% reliable. I typically have to reboot to get it working just right.
Sometimes the receiver of the X10 signals is jammed. My module is pretty old so I plan on grabbing a new/better model.
Let me know if you have any further questions, comments or concerns.
If your now used to the way that GMail puts an automatic delay on all outbound emails, you might want to set this up for Outlook as well.
This is based on these instructions for an older version of Outlook. Here is the equivalent for 2010:
1. Switch to the Home tab
2. Click “Rules” on the right
3. Choose “Manage Rules and Alerts”
4. New Rule
5. Under “Start from a blank rule”, choose “Apply rule on messages I send”, and hit Next
6. Hit Next again, you should be prompted with a dialog. Choose Yes or No as you see fit. I chose Yes, to apply this rule to all outbound emails.
7. In the next step hit the checkbox for , “defer delivery by a number of minutes”
8. In the bottom area click the section of the text “a number of minutes”, enter your delay duration (I chose “5”), and hit OK.
9. Hit next twice, and finally give your rule a name, I chose “Delay Send by 5 Minutes” and then hit Finish
Now all of your emails that you send will sit in our outbox for about 5 minutes. Initial testing shows that it is about 5 minutes and it is not perfect (probably a delay with the UI, or exchange or some where in between).
More Posts