I got off to a late start, having let the morning dissolve into a blur of blog updates, email checking, and social media socializing. I don’t feel bad about that (at least, not TOO bad) because I had a breakthrough insight about the nature of the resistance that comes when I do a certain kind of work: I get a literal headache, and its cause may be due to a lack of closure. Now that I’m mindful of it, I can start to deal with it.

The Morning

Today is the 2nd coding day of the week, and from the research I did yesterday I have a pretty good idea of what to do next: implement network communication between three distinct entities. That will provide me with what I eventually need to hook up with external sources of data, which will be a significant advance. I review Trello, Email, and Google Calendar, and for once I don’t have ANYTHING scheduled for the day! No evening meetings for once…

Then I get an out-of-the-blue invitation to lunch from an entrepreneurial friend I haven’t talked to in quite some time, and I decide that though I’m in the mood to work, I really do want to catch up. On top of that, the lunch location is near the bank and my business mailbox, so I can get some errands off my list. The lunch is good, conversation thought-provoking, and my errands largely come to pass.

OBSERVATION: I’m keenly aware that so far, the bulk of my week has been spent not creating new things. What I would call “pure creative work”. It’s less than 4 hours, I would say, if I don’t include the blogging. Actually, I should include the blogging, because those were significant acts of synthesis.

The Afternoon

It’s now 3:00PM, and I’m writing up this blog entry to reflect on the early part of the day. Since there is no evening meeting of any sort, I can actually work later. Woo hoo! Other than the network coding, there’s two other things I am determined to hit: some design work for another client that I’m looking forward to, involving early-stage concept for a report. Then I’d also like to get some time in on looking at a new theme for the website, which uses technology that I can use for yet another client. I should be able to hit all of them in the next couple of hours. I am expecting resistance, but I am going to be mindful of it and take notes.

Coding Websockets

First challenge: pull up all the necessary app workspaces. Development is primarily done on the Mac because it is unixy and sexy. The PC workstation serves as a secondary note-taking station, which is this blog post draft. Tomorrow morning, I will go through the notes and convert them into more readable prose.

• pull up terminal, chrome, sublime text on Mac
• start new nvAlt document to keep track of immediate code snippets
• connect to localhost
• connect to dev journal wordpress for longer form documentation

Second challenge: I am working on a conceptually NEW part of the codebase too, which means I have to come up with some way of keeping it nice and organized.

I write up brief explanation of the approach in my official dev journal. Ready to do some basic implementation. No headaches detected, probably because today I feel I have a working grasp of the Node-Connect-Express continuum and am more excited about jumping back into it. SOMETHING IS GOING TO HAPPEN.

Now, to write that first snippet of code. Feeling a twinge of headache. Deploying “anti-uncertainty” counter-vibes: “Let’s just take it a step at a time and not worry into the future”. Here’s some of the brain chatter of the first step:

I need a new filename. What should it be called? Calling it inqcomm now, for “InqSim Comm”…not sure if this is architecturally good, but going with it. Creating a folder in root…what should it be called? Calling it “server”, because it will alpha-sort to be next to server.js in the file hierarchy, which is the Express server that Mimosa includes. Creating file inqcomm.js in it. Now what should it do? First, let me require() it…with NodeJS, I don’t need to use dependencies because files are all local! Create working test stub. Rerun server and see if it complains. Now create test function and see if we can see a console log message. Testing that errors are reflected in console too. Seems to work. Great!

In the above, I’m just seeing if I can write insert my own code into some pre-existing server code, and that I can see error messages.

OBSERVATION: The headache began when I start to have to come up with names for the modules, where to put them, etc. I had to make DECISIONS, and I had to think about the future to make them, and I had to implement a chain of features to test my ideas. Once that was in, the headache subsided, though I am still feeling a bit drained and sleepy. AS SOON AS I STARTED MAKING DECISIONS, brain fatigue in a form of headache/sleepiness popped up. I should note, though, that I forgot to set up my Roost Stand to make the Mac more pleasant to type on; I actually have a bit of neck strain too.

30 minutes have elapsed 1530

Next, let’s test UDP, a kind of networking protocol that I need to connect to a remote motion tracking camera. Need to look up some references on UDP, so I’m reading docs at the NodeJS website. I take some notes in nvAlt, copying critical code fragments as I build up my understanding.

75 minutes have elapsed 1615

I have enough information to start writing a test server, at least conceptually. I’m stuck on a few things that are not explained in the NodeJS documentation…what is “socket membership” anyway? Headache ensues after reading through three search results that don’t tell me. I catch this rising headache, and simplify my expectations: scan for keywords, without expectation. In a couple of minutes I think it has something to do with “packet multicasting”, which I decide isn’t relevant in our application, which is peer-to-peer at the moment.

105 minutes have elapsed 1645

Writing the actual UDP code. There is one UDP socket thing that listens and responds, which I name UDP_ECHOER. Then I actually need a source of UDP datagrams, so I make another socket thing that is called UDP_EMITTER, which just sends something to EDP_ECHOER every second, which then mirrors what was received back to the sender. It works, but I am getting way more messages than I expected. It’s not a bug in my message-making code, but I had used the same port for both ECHOER and EMITTER; the echo was going back to itself infinitely! I’m amazed it didn’t crash, but maybe that’s because interpreted languages are inherently safer. I changed the ports so they are different, and it works!!!

135 minutes have elapsed 1715

OBSERVATION: I am always wondering if I’m too slow at programming. Is 2.25 hours a long time to do something so basic? I always think I should be faster. It feels like this should have taken 30 minutes, not two hours. Well, I guess that’s OK. I can argue that I am being meticulous about developing my understanding so I don’t make mistakes later.

Now that the UDP stuff is working purely on the web server, side, I have to now actually ship some message up to the web app, which is running in a web browser. That means using a new HTML 5 capability called Web Sockets. I spend some time looking up socket libraries, momentarily confused because many of the examples that come up are for the server side, not the web browser client side. Then I realize that Web Sockets are an actual HTML5 capability, and I don’t need to use a library to fake it through some means. Yay! Since this project is a closed system, I don’t need to worry about compatibility with older browsers that may not support Web Sockets.

I chug away at this, writing test code that takes a bit to get working right after a false start putting the code in the wrong place; it’s easy to confuse emitter with echoer conceptually. The code is pretty straightforward, otherwise, with the hardest part deciding where to put the test code. I have it working and committed to our repo after another hour and 15 minutes.

210 minutes have elapsed 1830

OBSERVATION: No headaches experienced in that last push. Maybe because the end was in sight. Maybe because I didn’t let myself fall into the negative I wish this was done and would go away mindset. In fact, I might have been in the FLOW state, just focusing on the problem at hand.

The Evening

It’s 6:30PM now, and I’m not exactly feeling fried, but I also want to take a break. There is still one major piece of work today, the visual design of a report that is based on my interpretation. The project is in early concept phase, so my visual design will be a conversation piece more than a finished spec. This is the kind of collaborative project I like doing. It’s actually kind of a big conceptual task, I realize. But first, DINNER.

I also download Minecraft and play it while eating dinner. It’s crude, but oddly compelling.

At 8:45PM, I’m sufficiently rested and start looking at the report design. I’m not sure where to start, which creates some resistance in me, but I remember that while I wish this was done NOW, I can easily just put in SOME time tonight and see where that goes. By now, the starting-up ritual is a bit more automatic:

• open my InDesign file, created the other day, so I have my project context available and in front of me.
• clear my mind as I stare at the InDesign file, and start answering the first question that comes to mind

The first question that pops into my head is, “what is the scenario”, so I start making one up based on past conversations I’ve had with the client. I write a stream-of-consciousness that outlines what I’m thinking and what I want, and over time I can start to imagine how the product might work, and what I might want to get from it.

45 minutes later, I have a few pages of text and an idea of what the report might look like. The InDesign document was helpful in that it kept my notes next to the diagram in an easy-to-manipulate manner.

OBSERVATION: What is missing from many of these “thinking tools” is an actual workspace where you can sort, arrange, and refine data in a reflective manner. Scrivener offers this in its multi-window interface, though it’s inherently linear. Other software approaches like mind mapping offer a manipulable space, but you are manipulating abstractions, not integrating actual assets as part of a production process. The output of a good reflective workspace should be something you can use to control a production process. Maybe what I’m talking about is a good pre-production tool that assembles production blueprints.

Takeaways

This is the first day that I was able to overcome a headache by lowering my expectations of source documentation, shifting the burden from the executive “I WANT THE GOOD STUFF NOW” mindset to production-style “Let’s just see what’s here and fill-in the rest.”

The role of the uber creative support software is also a little clearer: it’s a workspace where manipulation of creative elements can easily be done, and it looks something like an annotated scroll.

I also had a good time doodling in my day grid. I should do this more!