Thursday
04Mar2010

Mac Apps

DateThursday, March 4, 2010 at 06:30PM

I'm "moving out" of my Macs -- both the Mac Pro and the MacBook Pro -- at work, and I wanted to make notes about the software I have installed so when I get a new laptop (as soon as the MacBook Pros get refreshed...)

So here it is... a near-comprehensive listing of all the apps and tools I can't live without on my Mac.

AuthorMatt Miller | CommentPost a Comment |
Monday
15Feb2010

File Downloads with Django

DateMonday, February 15, 2010 at 04:26PM

We recently added some reporting functions to an internal tool, including an export-to-excel feature powered by xlwt.

The report generator wrote the reports to a temporary folder, then we used something like the following in a view to download the file:

filedata = open(settings.TEMP_FOLDER_LOCATION + '/' + filename,'r').read()
response = HttpResponse(filedata, mimetype='application/ms-excel')

That worked. Sortof. On some browsers the file was saved without the .xls extension. A little research turned up the Content-disposition header.

Now, all I had to to was add that header to the Django response. Turns out, that's pretty easy. The Django HttpResponse object accepts headers as if it were a dictionary. I broker the above code out into a method I could reuse, and ended up with this:

def tmp_file_response(filename):
    filedata = open(settings.TEMP_FOLDER_LOCATION + '/' + filename,'r').read()
    response = HttpResponse(filedata, mimetype='application/ms-excel')
    response['Content-disposition'] = 'attachment; filename=' + filename
    return response

Which does exactly what I wanted.

AuthorMatt Miller | CommentPost a Comment |
Saturday
16Jan2010

Scratching an Itch

DateSaturday, January 16, 2010 at 10:03PM

Unless you've been under rock the last few months (or you just don't read technology blogs like I do...) you're probably aware that Apple is anticipated to make a big announcement later this month. If the rumors are right, they're going to release the long-awaited Tablet.

As I've read the coverage -- the rumors, the predictions, the "leaks," the often wild speculation -- I've wondered if anyone is keeping track. Which bloggers have a track record of publishing accurate predictions and which are just blowing smoke.

In order to scratch that itch, I've been working on a database and a website, http://RumorScorecard.com. The idea is, in the weeks running up to an anticipated big announcement, I'll keep track of who's publishing what predictions. Then when (if?!) the big day comes, I'll tally the scores and see which sources knew what they were talking about.

I'm just getting started, but I'm planning to put a few hours in every night over the next week so that the site is ready to go for the potential Apple event the 26th or 27th.

Check out Rumor Scorecard and give me your feedback!

Update: Feb 4, 2010

I didn't make it very far on the rumor site, mostly because the week after I wrote that the organization I work shifted our Haiti response operation into full gear. I'll keep the site around though, and very possibly put it into action when the rumors start flying about the next big thing.

AuthorMatt Miller | CommentPost a Comment |
tagged
Tuesday
28Apr2009

The Unexpected

DateTuesday, April 28, 2009 at 05:32PM

I'm in Colorado all week working on a network and VoIP installation for my organization's new headquarters. They're moving in to a nice office suite, but we're pretty much doing the technology from the ground up. As with any project, getting all the pieces to fall into place at the right time can be a challenge. Here are some of the problems we've faced.

Problem 1

The 4-post server rack we ordered was delivered on time and waiting for us Monday morning. But when we opened the box, we found that all four posts were bent. Very bent. Unusably bent. The vendor promised a replacement... in 4-5 days. We're only here for 4 days.

How We Addressed It

We delegated the problem to several people who attacked it from different angles. While one of us worked with the vendor to see if  there was any way to expedite delivery of the replacement, we had two people in remote offices working on the problem as well. One started searching for local vendors using the Internet. The other had business connections in the Denver area and started calling them. Ultimately, we found a local vendor who had a rack that would work in stock. We drove across town to pick it up... problem solved.

While I was driving to get the rack (an hour and a half I could have been working on servers or terminating cable) I thought through the next few steps of the install to see if there was anything I could do to make them go smoother. I realized we needed to rent a ladder and a drill to pull some cable, so I used the extra time to find a rental company and reserve the gear we needed.

Lesson Learned

  • If you've got a time-sensitive problem, try multiple approaches at once and go with the first -- or best -- that succeeds. And don't be afraid to call and ask for help. How often do you think (or hear someone say) "If only they'd asked me, I could have helped with that."
  • Use the time while you're waiting on a solution to the problem at hand to think ahead and solve the problems you're going to face tomorrow. This can help make up for lost time.

Problem 2

The UPS didn't arrive when scheduled on Monday. After repeated calls to the vendor, we learned it was in town, but the shipping company wouldn't have a truck to bring it to us until Wednesday. That's a problem, because everything else depends on the UPS.

How We Addressed It

We kept talking to the vendor, and then to the shipping company until we got them to let us come pick it up at the warehouse. We drove across town (again) to the warehouse, took the pallet containing the UPS apart, loaded it into the rental -- thank goodness it had been upgraded to an SUV -- and bought it back.

Lessons Learned

  • The lesson from this one is persistence. Keep talking to the people who can help you solve the problem. If two contacts are pointing fingers at each other, go back and forth until you get to a solution. Ultimately, it's your problem and you're going to have to solve it. When other people or organizations are involved, good -- and sometimes persistent -- communication is a must.

The Crazy

We've had a couple who-could-have-expected-that occurrences.

  • Right after we arrived Monday, the office manager got locked in a room -- where the handle didn't have a lock. The locksmith had mad a mistake installing the handle and you couldn't open the door once closed. We had to climb through the ceiling to get in the room and disassemble the door handle. Then the locksmith came and reinstalled it ... correctly!
  • When we arrived with the UPS -- several hundred pounds of UPS -- we were greeted by the elevator repair man. Thankfully, we only had to wait an hour.

Lessons Learned

  • This lesson is easy and hard at the same time: sometimes you've just got to laugh it off and move on.  Stuff happens.

In Conclusion

One of my goals for this blog is to record things I'm learning. When I sat down this afternoon to write a post, I was disappointed. "I haven't learned any cool geeky stuff this week, I've just been dealing with CRAP." But I have had important lessons reinforced through these experience. I'd be remiss if I didn't document that.

Have you had similar experiences?  What have you learned from them?

AuthorMatt Miller | CommentPost a Comment |
in
Tuesday
14Apr2009

Grading VoIP Call Quality

DateTuesday, April 14, 2009 at 12:58PM

We've been doing a lot of testing of our Voice-over-IP systems lately. We experiences some pretty horrendous voice quality in a series of high-profile conference calls last week, and are looking to ferret out the root causes and fix the problem.

One of the questions we've had to ask ourselves is, "How do you measure and record the audio quality of a call?" There are some pretty sophisticated methodologies and grading scales out there for assessing call quality, but everything I can find seems to be overkill for what we're trying to do -- test various configurations, record the results, and be able to look at the results and choose the configurations that work best.

Since I couldn't find a system that was simple enough to implement very quickly, we started assigning letter grades to the calls we were listening to. After a few calls, some patterns emerged and we were able to clearly state why we thought each call deserved a particular grade. Here's what we came up with.


Grade Call Characteristics User's Response
A No problems, Clear natural sound. I didn't even notice the audio quality.
B Some minor delays or tinny unnatural sound. It sounded good enough.
C Delays, tinny unnatural sound, minor dropouts, or a combination of minor problems. The sound was annoying.
D Barely intelligible, very unnatural sound, "underwater," periodic dropouts. We had to work to have a conversation.
F UnintelligibleWe were not able to communicate.

img_1719

To grade calls, we rigged a handset over the speaker on a laptop and played a sample from an audio book. We chose a recording where the narrator uses as steady cadence and low dynamic range, the Audible.com version of Malcom Gladwell's Tipping Point. This worked much better than having someone talk into the phone. (You really can't assess quality very well if all the other person is saying is "Can you hear me now?")

And finally, here's a table showing call quality degrading as we add callers. We're routing each call out and back over a T1 line using the uncompressed G.711 codec. We graded audio quality on both the conference call as well as a second call between two endpoints over the same T1.




Callers to Conference G.711 Channels Routed across T1 Conference Quality Other Call Quality
6 14 A A
716A A
8 18 B (some delays) A
9 20 D (periodic dropouts) F (unintelligible)

I was pleased that the results of our test are aligned with these figures posted on the voip-info.org wiki. The 1.54 Mbps capacity of our T1 divided by the Nominal Ethernet Bandwidth of a G.711 SIP channel (87.2Kbps) gives a maximum of 18 simultaneous calls, which is exactly how many we were able to place before things broke down.

Geek side note: A T1 carrying regular voice calls on for the phone company, or PRI, uses the G.711 audio format, but without the overhead for IP headers -- a PRI uses time division to split the line into channels -- phone companies are able to fit 24 channels on a single line (64Kbps x 24 = 1.54Mbps.) Usually, 23 are used for voice and the 24th is used for data like Caller ID information.

In the next week or so we'll be testing other voice codecs. We're leaning toward G.729. Although it has a license cost of $10 per simultaneous channel, it promises good call quality and 40+ channels on a T1.

AuthorMatt Miller | Comment2 Comments |
in
Page 1 2 Next 5 Entries »