Posts

Showing posts from June, 2018

Debugging Tip: Fix Anything

This is from my fiend Bill Burdick. When you can't immediately find a bug, start fixing everything that isn't right . Refactor. Make things clear. Make things consistent. Rewrite things that don't follow best practices. Fix other bugs. Don't trust your judgement of what is or isn't related to the problem. If you really knew that, you wouldn't be stuck.

Programming as a Cure for Burnout

Just putting this here so I will see it next time I need it... If I've been fighting with a bug, or a new technology that just isn't working for me, I eventually lose energy. A solution that has worked for me is to find a way to write more working code , while still staying somewhat close to the problem. For example: Write "toy" code that uses the new tech I'm stuck on. Write, and test, a wrapper for something I've partially learned which is still being troublesome in my project. Review existing code and rewrite it with a cleaner design Write more tests The point is to write more working code, any way you can . Successful coding is fun and makes our brains happy. We get discouraged when we are not writing working code. So the trick is to find some place close to the problem where we can  write working code, and write working code there until the whole thing is flowing again Personal examples: The previous incarnation of my study-project

One-line Web Server

python -m SimpleHTTPServer 8000 Serves files from where you start it. Or for Python 3.x… python -m http.server 8000

Pattern for functions that get promises, and then create and return new promises

There's nothing deep or official about this. But I'm new to promises and it took me a while to work out how things wanted to nest when I used a function that returns a promise, and then wanted to return a promise of my own. function myFunction(myArgs) { return new Promise(function(resolve, reject) { callThingThatReturnsPromise(myArgs) .then(function(gotThing) { //compute with gotThing resolve(computedFromGotThing); ).catch(err) { //do stuff with error reject(computedFromError); ); ); } The point here is that we want to write the.then(...) and .catch(...) handlers for the promise we get in a context where we can see the resolve and reject functions for the promise we are creating. And, just to review... When using a promise, we write handler functions to pass to then and catch . When creating a promise, we are* given resolve  and reject  functions to call. * Technically we will

console.table(...)

Try this in your browser's JavaScript console. console.table([{a:1, b:11},{a:2, b:22}])

REPLs for testing, or exploring, or something...

I like REPLs (read execute print loops). In my first Java QA job, we were testing a Java API for cash registers, a world that didn't have a whole lot of tooling at the time. I had written a bunch of tests as classes implementing an interface with some kind of "doTest" method. And I discovered that with just a few extra lines of code, I could read a line from stdin, parse the name of one of the test classes followed by optional args, make an instance of the test class, call its doTest(...), and print. And this was a great way to play with the library we were testing. And it was scriptable. :-) This was definitely my favorite thing from that job. I even gave it something like global variables, using a hash table in which values could be linked to names using a SetValue "test". And then the names could be used as arguments on subsequent lines. Later we started using JACL (A Java implementation of the Tcl scripting language). JACL code could reach into Java