clipboarded: September 2011

September 29, 2011

partial application in Javascript part 3

Here is the last part of the videos on partial application. We improve the code from previous videos and make it handle a variable number of parameters.

In the video, I mention that n is the number of times we will have to apply partial application before the underlying function is called. That is misleading. The situation is actually a little better than that. n is really the number of parameters the underlying function cares about. After n parameters are passed in, the original function will be called. Whether or not we pass in the parameters all at once (a, b, c) or one at a time.

Here is the final code:

 1 <html>
 2     <body>
 3         <script language="javascript">
 4 
 5             Function.prototype.partial = function(n){
 6                 var original_function = this;
 7                 var args = [];
 8 
 9                 var recursive_partial = function(){
10                     args = args.concat([].slice.apply(arguments));
11                     if (args.length >= n){
12                         return original_function.apply(null, args);
13                     }
14                     return recursive_partial;
15                 };
16                 return recursive_partial;
17             }
18 
19             function addTwoNumbers(a,b){return a+b;}
20             function addThreeNumbers(a,b,c){return a+b+c;}
21 
22         </script>
23 
24         Partial application #3
25 
26     </body>
27 </html>

September 26, 2011

partial application in Javascript part 2

Here is part 2 of the videos on partial application in Javascript. We take the initial prototype and make it handle three parameters.

Here is the code:

 1 <html>
 2     <body>
 3         <script language="javascript">
 4 
 5             Function.prototype.partial3 = function(){
 6                 var original_function = this;
 7 
 8                 var args1 = [].slice.apply(arguments);
 9                 return function(){
10                     var args2 = [].slice.apply(arguments);
11                     return function(){
12                         var args3 = [].slice.apply(arguments);
13                         return original_function.apply(null, args1.concat(args2).concat(args3));
14                     }
15                 };
16             };
17 
18             function addThreeNumbers(a,b,c){return a+b+c;}
19 
20         </script>
21 
22         Partial application #2
23 
24     </body>
25 </html>
26

September 23, 2011

partial application in Javascript part 1

I recently recorded a few videos on partial application in JavaScript. In part 1, I explain what it is and I provide a short code snippet as a first draft. I will build upon the code snippet in the subsequent videos.

Here is the code that I am using:

<html>
    <body>
        <script language="javascript">

            Function.prototype.partial = function(){
                var original_function = this;
                var args1 = [].slice.apply(arguments);

                return function(){
                    var args2 = [].slice.call(arguments);
                    return original_function.apply(null, args1.concat(args2));
                };
            };

            function addTwoNumbers(a,b){return a+b;}

        </script>

        Partial application #1

    </body>
</html>

September 20, 2011

browser testing - looking back

My last project involved quite a bit of browser testing. Here is a recap video describing lessons learned.

Lessons learned

1- Avoid browser testing: it's too expensive
   .do unit testing
   .do integration testing
   .do view testing (including JavaScript testing)
   .do controller testing
   .build your confidence so you don't have to test using a browser

2- Only test high-level critical bits
   .emulate the user
   .test complete user journeys

3- Manual testing is still needed
   .to test UX
   .to test with multiple browsers
   .to do exploratory testing

4- Non-technical people probably won't be able to write tests w/o help
   .programmers are needed to implements steps interacting with new features
   .that's okay - we like having a job

Secondary lessons (more technical)

1- Forgiving assertions are useful
   .do not fail the test right away if you can avoid it
   .forgiving assertions provide more coverage and still fail the test if assertion failed

2- Do not test for absence of stuff
   .hard to be sure the assertion is written correctly if the outcome is negative

3- Anchors help with timing issues
   .when the content is dynamic - use anchors
   .wait for something you know to be there before going for the dynamic elements

4- Semantic HTML helps
   .when the HTML is meaningful - the tests are more robust
   .semantic HTML helps avoid brittle xpath expressions

5- Minimize business logic
   .do not test for sorting or any other kind of calculations
   .do not test for things that should be unit-tested

September 4, 2011

getting things done

For a few weeks now I've been using some sort of GTD system to manage my todos. The GTD -- Getting Things Done -- system is simple but I guess it's got a few things to it so there's a book about it.

To me, it boils down to how to manage a bunch of todo lists. I have a handful of todo lists, one for each "project" that I want to get done. And I tag individual todos with labels like @next, @soon, @waiting, or @reference. I try to always write down a todo for everything I want to achieve and I sort it into one of the projects.

When I go into planning mode, I tag lots of todos as @next. A quick search for that label will give me my current consolidated todo list. As I get those todos done, I delete them or remove the label and tag some more... Ring around the rosie.

The GTD workflow is easily understood from the following diagram:

The GTD workflow - copyright David Allen

A lot of software options are available to implement some sort of GTD workflow. But I have settled on the Springpad Android app. It's got bugs but it's very powerful and it does everything I need for GTD-style management. Hopefully they'll sort out the bugs soon enough.

Springpad's home view

When I am really totally obsessed about getting things done, I sometimes use the Pomodoro technique. This one also has a book but frankly, it probably does not deserve that much literature. It's too simple: set a timer for 25 minutes and that's the time you have to get something done. Then take a five-minute break. Rinse and repeat. Everything else is fluff. There is an Android app for that too.

clipboarded