are somewhat resolved by this insane set of hacks!

Now go there and save yourself some time. These steps work with getting the Broadcom 4331 wireless chip recognized, so your wifi will finally work. I still have no ethernet connection, but I can't be bothered right now, I already wasted enough time on this today ;)

We've just introduced a change to Mozilla's Mochitest harness to improve test run times, as per Bug 367393. This involved the removal of unnecessary MochiKit usage. We found that we were including a minified version of MochiKit, packed.js, in all our tests and within the harness, but we would only use a small portion of this enormous suite. That added an extra load of about 5 minutes per debug test run, so we removed MochiKit from our harness and added replacement functionality to SimpleTest. Note that the SimpleTest.js file in MXR may not yet be updated, so pull the latest mozilla-central code to see latest changes!

What this means for you: If you're writing a test that doesn't require MochiKit, please do not include packed.js in your test. This just adds extra load. If your test does require some part of MochiKit, please check if that functionality isn't already part of SimpleTest. If it isn't, then include the only the relevant parts of MochiKit (ex: <script type="text/javascript" src="/MochiKit/Base.js"></script>) instead of pulling in all of packed.js.

... and I realize that it actually made me an avid reader!

So I bought a Kindle a few months back. I bought it because I got out of the habit of reading, and more into the habit of playing mindless videogames (Team Fortress 2 and Left 4 Dead 2) and I wanted to kick-start my interest in reading again by pushing money into it as an investment. So, my thoughts on this investment? It was a glorious one!

The low price-point of books on the Kindle store enticed me to buy books I would otherwise have not have purchased, but rather have borrowed from a library or a friend or something. So I started by joining my two interests, gaming and reading. I will admit to this incredibly nerdy purchase: I bought Mass Effect Ascension, since I love the Mass Effect universe. That book was devoured within 2 nights. It wasn't the best book (or even a good book, sadly), but it got me interested in novels again, so I picked up some of the stuff on Amazon's Free Classics Section, and read Alice in Wonderland, War of the Worlds, and a bit of Picture of Dorian Gray, until I realized it was a terribly boring book about a bunch of whiny guys who have everything in the world but still want more. I bought a few more books like Mort by Terry Pratchett, which was a fun read. These books piqued my interest in reading again, and outside of the Kindle world, I'm current reading Carl Sagan's The Demon Haunted World, going through some of Dijkstra's Manuscripts, and feverishly checking reddit for more things to consume!

The financial investment totally guilt tripped me into using the device, and it is actually working. Also, the speed at which you can buy and download books (um, near-instant) combined with my impulsiveness makes me buy books, and it's portable, so I actually read it wherever I go. It hasn't been damaged in my travel bags yet (I got a leather case for it). The guilt made me actually force myself to find time, and I finally got back into the habit of reading. I've finally moved past the guilt-tripping, and now it's habit again. Joy!

As usual, I've been a delinquent blogger. But I've finally come to the point where my sentiments about my role and my work have finally (somewhat) gelled.

I wasn't always a computer geek. Sure, I was always interested in computers, but I never programmed anything before setting foot in university. I just liked solving problems and building things. When I chose Computer Science (quite randomly, as you'll soon find out), I never really understood what developers did outside of code-monkeying, and I was not at all clear about what my role would be as a software developer.

I entered my first year of Computer Science without ever having programmed before. Why? Well, I actually wanted to be a doctor, but realized I only really liked the science and the romanticized ideal of helping people. I didn't actually want to see anyone die, or diagnose anyone with some terrible illness. A part of you has to be removed from your patient, and I didn't want to sacrifice that feeling of solidarity; I wasn't, and am still not, okay with death or chronic illness. Also, the unimaginable hours would have made me go insane. So in my last year of CEGEP (a Quebecois flavor of pre-university and vocational school), I opted to go into engineering because I liked solving problems. So which kind of engineering to pick? I was leaning toward materials engineering, since it combined all my favorite subjects, but I had a strange and rather inexplicable desire to try something completely different. Both my career counselor and father told me that computer science was something I'd probably be good at, and potentially enjoy. I had never been the kind of person to be afraid of a computer, or be afraid of learning something new, so I said "What the hell, why not try it out?" My plan was to take my chances and try Computer Science at Waterloo for one year, and if I didn't like it, I would go back to McGill for their materials engineering co-op program. Now that I reflect on it, my decision was pretty out there, but I'm extremely glad I took that chance, because I loved the material the first day of class. But going to Waterloo is far from just an academic experience, it also ensured that I would be going through a series of internships. The internships were a key factor in deciding where I wanted to go for school, because I had no idea what being a "computer scientist" would entail. I knew that with this program, I would be on my way to an eye-opening journey.

My first internship was a strange one. I was totally new to programming, so I opted for a QA job (I started class 8 months prior, so at that point I barely even understood the concept of tree traversal). The job itself was something I had no passion for; I love building things and solving problems, not trying to break other people's software or writing test scripts. The environment wasn't one for me either. It was quite corporate, and not one where I felt I could easily contribute outside of my designated role as tester. After that experience, I realized I should move on to developer positions, since my passion lay elsewhere.

My next few internships were at start-ups, and they were great. I loved wearing different hats, and doing whatever was needed to get the job done. I loved the chaos. I loved being part of such small teams, and building out systems from the ground up. It was fun, exciting, and I was always learning something. I had applied a lot of the academic knowledge I acquired, as well as just general coding principles and designs. Having done rapid development for a few internships, I wanted to see what else was out there.

This brings me to my last internship. I heard good things about Amazon, and it seemed like the perfect introduction to a "corporate" developer environment. I'm now in my 3rd month here, and it has definitely been an interesting experience. The small team sizes and the amount of freedom we are given is very reminiscent of the start-up culture. The real difference was the involvement I had with the entire software development lifecycle.

At start-ups, you're always on the beginning part of that cycle. Get specs (or at least some data or proof of concepts), build, build more, refactor, build again, test. Scrap occasionally. Build more. At Amazon, I was given many tasks at different levels of the cycle. The interns are given projects where they must seek out the right people to get specs from, design a solution, build it, and release it. I had never been given any customer-facing roles, so this was a new and truly enlightening experience for me. I had also been tasked with adding parts to a maintained system, and had seen quite a few projects being obsoleted and replaced by better solutions. Students always hear about this 'software development lifecycle' and we all know how it works, but seeing this concept in action and being part of each division gave me a real appreciation for the work we all do as software developers. There are many lessons I have learned here so far, but it can all be summed up by the fact that this experience has made me truly understand the software lifecycle, and my role as a developer in creating software solutions. To continuously build and improve, and listen to your users.

I had always had a narrow field of view on the work I was doing. I understood my role as a coder, but not as a developer. My job isn't just about coding, but also working with others to find a solution that helps everyone, finding and addressing issues, and understanding to let go of something when the time comes. It is a true and full form of constant problem solving. I completely get that now.

This internship was the perfect conclusion to my undergraduate career. I have learned so much from school and from my internship experiences, and I now feel like I have a grasp of what my role is, and where I want to go from here. We'll see what the future brings!

So I got my Arduino Duemilanove earlier this week, and I've been completely stoked. After getting blinky going, I promptly took out my breadboard from the plastic container, assembled a jumble of jumper wires, resistors, LED and buttons into what became an on-off switch for the LED. Fascinating. Bloody gorgeous. What next?

Well, since I have the button presses as digital input, and the LED as digital out, I thought a neat project would be to record a 3 second button input pattern, and replay that pattern through the LED. That would familiarize me with some of the Arduino's code, and would just be really fun to see live.

For the LED, I connected a jumper cable from the digital out (pin 11) to the breadboard. Then I connected a 1k ohm resistor to the LED, then a jumper cable from the LED to ground. For the next part of the circuit, I connected a jumper cable from a digital read slot (pin 2) on the Arduino the breadboard. I then added a pull-down resistor of 2k ohms from the jumper cable to ground, and lastly, I connected the 5V slot to the button via another jumper cable. This mini-project took about 1-2 hours (coding, after a day of coding, can be tiresome on the ol' noggin), followed by 1 hour of button pushing in awe :)

In any case, I've included a video of it, and the code. Word of warning about the code: It can definitely be done more efficiently (ex: arbitrarily large arrays = fail), I am a computer science major after all, but I also have better things to do:P I haven't really looked at the Arduino API, and it's pretty much just hacked together. Anyway, here's a video, a sketch of the circuits, and the code:

Code:

  // set pin numbers:
  const int buttonPin = 7;     // the number of the pushbutton pin
  const int ledPin =  11;      // the number of the LED pin
  
  // Variables will change:
  int buttonState;             // the current reading from the input pin
  int lastButtonState = LOW;   // the previous reading from the input pin
  
  // the following variables are long's because the time, measured in miliseconds,
  // will quickly become a bigger number than can be stored in an int.
  long lastDebounceTime = 0;  // the last time the output pin was toggled
  long debounceDelay = 50;    // the debounce time; increase if the output flickers
  int hold = 0; //keeps state of the button
  int beeps = 0; //number of button pushes
  int start = 0; // are we starting a new pattern?
  long startTime = 0;
  long duration = 3000; //duration of the recording
  long delayArray[200]; //no dynamic arrays! randomly large number. shut up.
  
  void setup() {
    pinMode(buttonPin, INPUT);
    pinMode(ledPin, OUTPUT);
  }
  
  void loop() {
    // read the state of the switch into a local variable:
    int reading = digitalRead(buttonPin);
  
    // check to see if you just pressed the button 
    // (i.e. the input went from LOW to HIGH),  and you've waited 
    // long enough since the last press to ignore any noise:  
  
    // If the switch changed, due to noise or pressing:
    if (reading != lastButtonState) {
      // reset the debouncing timer
      lastDebounceTime = millis();
    } 
    
    if ((millis() - lastDebounceTime) > debounceDelay) {
      // whatever the reading is at, it's been there for longer
      // than the debounce delay, so take it as the actual current state:
      buttonState = reading;
      if (reading == LOW){
         hold = 0; //otherwise, we're still holding the button!
      }   
      if(hold == 0){ //if the button was let go
        if( (start == 1))
        {
          long time = millis();
          if  ((time - startTime) < duration ){
            if (buttonState == HIGH){
                 beeps++;
                 delayArray[beeps] = time;
                 reading = LOW;
                 hold = 1;
              }
          }
          else{
            
            //replay the signals on the led
            int i = 0;
            long lastTime = delayArray[0];
            long now, next, span;
            digitalWrite(ledPin, HIGH);
            delay(150);
            digitalWrite(ledPin, LOW);
            for(i=1; i<=beeps; ++i){
              next = delayArray[i];
              now = millis();
              span = now + (next-lastTime);
              while( (span - now) > 0){
                now = millis();
              }
              digitalWrite(ledPin, HIGH);
              delay(150);
              digitalWrite(ledPin, LOW);
              lastTime = next;
            }
            start = 0;
          beeps = 0;
          }
        }
        else{
          beeps = 0;
          if(buttonState == HIGH){
             start = 1;
             startTime = millis();
             delayArray[0] = startTime;
             reading = LOW;
             hold = 1;
          }
        }
      }
    }
    
    // save the reading.  Next time through the loop,
    // it'll be the lastButtonState:
    lastButtonState = reading;
  }