Good read: The value of Ignite

3 December, 2013 § Leave a comment

Recently I got a shout-out from Tricia Broderick in her blog post, “The value of Ignite“. The post was a great reminder of what someone can accomplish when they step out of their comfort zone and try something they’ve never done before.

We held multiple of these “Ignite” events at TechSmith. At each event we had about eight presenters who covered various work and non-work related topics. The twist to the presentations is that each slide can only be on-screen for 15 seconds (auto-advancing) and you only get 20 slides.

These turned out to be great activities for people to learn more about their coworkers as well as get practice presenting. See Tricia’s blog post for her take on the event.

Tools & Processes for ensuring software quality at Mozilla

11 December, 2012 § 2 Comments

Last week I gave a talk at TechSmith about some of the tools & processes for ensuring software quality at Mozilla.

TechSmith develops multimedia software based around various screen capture uses. Some of their most popular software is Camtasia Studio and Snagit.

Like Mozilla, they use continuous integration, unit tests, manual testing, and code reviews to maintain software quality.

The talk was recorded and I hope to get a copy of the talk to upload here and share with others. In the meantime, I’ve included a link to the slides below:

Tools & Processes for ensuring software quality at Mozilla

Please let me know if I made any errors or omissions.

Seven Things You May (or May Not) Have Wanted to Know About Me

21 July, 2011 § 5 Comments

Browsing some of the Mozilla blogs, I came across JOEDREW! \o/’s blog post covering the seven things that people may or may not have known about Joe. Normally with these posts, you write one when you get tagged. I didn’t work at Mozilla when these were going around, so I’m gonna cheat at this 🙂

I’m Jared Wein, also known as JAWS. I currently work on the Firefox front-end user interface team, out of Mozilla’s Mountain View office, implementing many of the great designs that the Mozilla community comes up with.

Here are the rules for this particular meme

  •     Link to your original tagger(s) and list these rules in your post.
  •     Share seven facts about yourself in the post.
  •     Tag seven people at the end of your post by leaving their names and the links to their blogs.
  •     Let them know they’ve been tagged.

My seven things:

1. I haven’t owned my own car for over 7 years. I got my first (and only) car when I was in high school. It had over 200,000 miles when I bought it (for $1,200) and I sold it for the same price two years later with over 230,000 miles on it. Since then I’ve gotten around using mopeds, bicycles, buses, trains, and occasionally borrowing a car from a family member.

2. I started working at my first job when I was 13 years old. I officially joined the payroll when I turned 14 years old, and worked about 20 hours a week all throughout high school. I continued to work through college, allowing me to pay more than half of my tuition out-of-pocket. In total, I’ve worked at an ice cream store, senior citizen center, real-estate company, university computer center, and a couple software companies.

3. I’m related to one of the worlds best bass-guitarists and lead singers, Geddy Lee of Rush. Geddy and I are 1st cousins once removed. Once a year or so, our family gets the opportunity to attend one of Rush’s concerts and hang out back stage.

4. When I was in elementary school, I attended a summer camp on the other side of the city. After camp let out, instead of waiting for my Mom to arrive to pick up me and my friend, Matt Bonefeld, we decided to walk home. My Mom didn’t really appreciate the fact that her 7 year old son was walking 4 miles home, but we made it home safe 🙂

5. Throughout middle school and high school, I worked tirelessly on a campaign to get a local skate park built. I started going door to door with my friend Evan Goodman and my brother Matt Wein to raise money. After we had raised $200, we attended one of the Lansing Area Skate Bike & Recreation Foundation meetings. The board members were surprised to see us walk in with the unexpected donations. Matt, Evan, and I eventually became a board members, playing a large role in raising over $200,000 for the skate park.

The skate park got built and opened in 2002 to much fan fare. The park was constructed by Team Pain, the group that also builds the skate parks for the X-Games.

6. My favorite TV series is Tha Ali G Show. I really like tongue-in-cheek comedy, and I think Sacha Baron Cohen does a great job at putting people in awkward situations. I have seen every episode of Tha Ali G Show, as well as a couple of his movies from the U.K. and the U.S.

7. I used to have an afro when I was in high school. At it’s longest point, I could pull hair down to reach my bottom lip. Since my junior year in high school I’ve been keeping my hair cut pretty short.

And now the people to tag:

  1. Randall Brown, because he’s a great story teller.
  2. Felipe Gomes, one of the happiest people I know.
  3. Frank Yan, a CSS ninja who finds great uses of ::before.
  4. Betsy Weber, one of the best Evangelists in the software industry.
  5. Davin Granroth, my web development mentor when I was at MSU,
  6. Justin Dolske, World’s Best Manager & Bacon Connoisseur
  7. Cameron Flint, open-source enthusiast and great developer.

Campfire vs. IRC

8 July, 2011 § 2 Comments

I’ve now had the opportunity to use both 37signals’ Campfire and IRC at work. With these experiences, I can now provide somewhat of a comparison between the two chat platforms.

Why should you choose Campfire?

I used Campfire while working for TechSmith on the Camtasia Relay team. Our team had a very colorful chat room that was often filled with animated GIFs and funny pictures. We made great use of the embedding features of Campfire, such as YouTube links, emojis, and sounds.

Campfire worked well for our team. It provided a single source of logs, as well generally not requiring any extra IT resources. Once in a blue moon the Campfire servers would go down, but it was never anything terrible.

Some of the employees wrote bots as well as browser extensions for Campfire. These added some nice customizations to the chat rooms of the various teams.

At one point we migrated Campfire accounts and lost all of the logs prior to the move. It was sad that 37signals didn’t offer a way to transition logs to the new account.

Why should you choose IRC?

I use IRC at Mozilla to chat with my teammates on the Firefox team (feel free to join us in #fx-team on IRC has been around forever, and there exist many mature bots.

By default, the IRC server doesn’t appear to do logging, whereas many IRC clients offer logging capabilities. I haven’t seen the IRC server go down here yet, but I haven’t been here that long either.

On the #fx-team channel, there is a bot called firebot that can pull up bug reports as well as provide details as to when users were last seen.

There is a very strong community and culture that has formed around IRC. IRC probably requires more technical work to setup and maintain when compared to Campfire, but the organization running the server is in control of the whole system.

What do I recommend?

Campfire requires authenticated access, and by default IRC does not. Campfire also costs money whereas IRC is free. As a chat platform for your software team, I would recommend using IRC. I have more confidence in the 3rd-party IRC bot/customization community than in a propreitary 37signals one.

Campfire is easier to learn for new users, but doesn’t provide as much depth as IRC. For a technical staff, I wouldn’t be worried about the technical hurdles of IRC.

  • The get-up-and-go option: Campfire
  • The stick-with-it option: IRC

Performance Improvements of

23 May, 2011 § 1 Comment

The latest release included a couple speed improvements that were quietly included.

URL improvements

The first improvement was one requested by Kyle Mulka, of Twilk, during a visit to TechSmith. Kyle mentioned that he wished the short URLs would stay short after the web page was accessed. He mentioned that a lot of users like to copy and paste the URL from the address bar and use it in tweets.

I spent a bit of time researching what we would have to change to fix this issue, and in a couple of days we had the changes implemented.

This change also brings about a nice speed improvement to the loading of pages on Previously, when a piece of content was visited, the server would reply with an HTTP Status Code 302 - Found. This causes the browser to then load the page at the redirected location. This little bit of communication takes time, and with our new change we have removed this initial hurdle.

Here is a graphic showing the change in loading times:

With this improvement, we have increased the speed of viewing your content by 4.1% on average. If you are viewing your content from outside of North America, you can expect an even larger speedup.

Reduced page size

The second improvement that was added to was a new library layout. Much care has been taken to reduce the filesize of the webpages, to the point where loading up my library using the Library (beta) only uses 1/4 of the bytes yet sends more data. The Library (beta) also makes 11 less network requests than the current library. This means that your library is now more accessible under tighter network conditions such as 3G.

Managing your work email

5 April, 2011 § 1 Comment

Email is the predominant form of communication in many workplaces today, including at TechSmith. It is very easy to receive about 30 pertinent emails per day, as well as another 100 or so that consist of check-in notices, bug status updates, build notifications, etc.

Finding time to respond to emails, and the priority of which emails to respond to can be a task in itself. Some of my coworkers have different approaches to organizing their emails.

I’ve seen some that are meticulous in their folder organization, and others who make sure to reply to every personal email within 24 hours.

I probably fall somewhere in between. My work email account has:

  • An inbox
  • An archive folder
  • Filtered email folders (Changesets, Build Notifications, Sales Updates, and Off-topic)

Emails that land in my inbox are first priority. A couple times a day I will take the opportunity to sort through those emails. I don’t reply to every single one, but I try to file most. As a rough guideline, I try keep less than a screens-length of messages in my inbox at a time.

If I have read the email and replied (if necessary), then I will move the email to my Archive folder. The Archive folder exists purely for historical purposes. Once a while I will need to scan my history to find an email that someone mentions. I try never to delete an email. With hard drive storage so cheap these days, there should be no reason to delete tiny 10kb emails.

The filtered email folders get perused less often. A couple times a week I will read the changesets (aka check-ins) that have been landed on a couple projects at work that I am interested in. Build notifications almost never get read, they’re there just in case someone breaks the build (which never happens now that we are using gated builds). Sales updates and off-topic emails get read when some spare time comes along.

I find that this type of email management is simple and easy to control, and I recommend you try it out.

A response to “Comments: A Dissenting Opinion”

4 February, 2011 § 5 Comments

This past Thursday, our second post of the new Dev Corner was published and featured thoughts on code comments from Matt Mercieca.

The post is really well written and generated a lot of conversations within our internal development blog at TechSmith. Code comments are one of my bike-shed problems (I prefer green by the way), but I do feel inclined to respond.

Much of the post pits “how-comments” versus “why-comments”. I believe that it is well understood that “how-comments” are little cared for. For example, the comment in the following code offers no value to the reader:

//print out array
for(var i in objects) {

However, the “why-comments” is where the real discussion is. Respectfully, I stand on a different side of the fence when it comes to “why-comments”. I believe that what can be written as a comment can also be written as a function or variable name. Consider the following two code samples:

var printOrders1 = function()  {
  // this query is a hack due to weird SQL Server Query Optimizer bug
  var orders = sqlConnection.execute('SELECT TOP 1000 FROM tblOrders WHERE ...');

var printOrders2 = function()  {
  var executeQueryForOrdersWithHackForQueryOptimizer = function () {
    return sqlConnection.execute('SELECT TOP 1000 FROM tblOrders WHERE ...');
  var orders = executeQueryForOrdersWithHackForQueryOptimizer();

I feel that the second version contains the same information as the first version, but will be read more often. As code gets duplicated (unfortunately), sometimes comments get stripped. It is less likely that a function like this will get renamed to a more innocent name.

Where do you stand?

Where Am I?

You are currently browsing the TechSmith category at JAWS.