[Official] Stream of consciousness from a web programming, art admiring, lovable rogue.

First impressions and setting the tone with clients

John Atherton feeding Spam to a wild fox at the Kukak Bay, Alaska, archaeological camp in 1964
Image courtesy of gbaku

We really only have once chance to make a first impression. Whether it's a new friend, a potential collaborator, or a new client. The first impression sets the tone for all other interactions that come after it. Which is why it's important to be aware of how we present ourselves, what does one say, and how do we say it.

The first time we meet someone a template is set, a pattern is formed that will influence every interaction we have with that person. If we laugh and have a good time then they will expect to laugh and enjoy themselves the next time we meet. It's not a conscious thing, rather our brain picks up on the emotional high points of our interaction. When again we meet; our brain looks into it's depths to find any memories of this person. Our subconscious looks for patterns, and uses them like a script of how to act. It's a survival mechanism. Was I in danger the last time this happened? Was I happy, did I live, was I hurt?

Brain Patterns

By reacting to patterns our brain helped us survive in the wild. Though we are no longer in any great danger (those of us in First World countries anyways) our brain still behaves the same. We are not on the great savanna anymore, and rarely do we face down creatures that want to eat us. Yet the brain's habit remains. Only now it saves us at different times. Such as when we meet someone new.

Our brain records the emotional high points of our new meeting, our new friend, and stores them for the next time we need them. A firm handshake and steady eye contact, a weak voice and a poor stance, or bouncing off the walls with energy. Next time you meet these will be the expectations they have.

Setting the tone with new clients

When you meet with a new client how do you act; how do you let them act? If you kowtow to them, thanking them every other moment for using your service, they will expect the "yes sir" from them every time you meet. What happens when they want features that might not be the best solution for their problem? If you bended to their every whim before they will expect it again, even if it hurts the project.

Similar if you bully and push a client around they will expect it and could be hesitant to ask questions or offer insight into their specific business.

The best approach is to take the middle path. Be kind, honest and open. Let the client speak on their opinion and thoughts, but be firm in guiding them towards the idea of working together to find solutions. If you lay the groundwork early you can set a tone of mutual respect and cooperation.

Doing this from the very beginning makes it easier to create a foundation of a good relationship. It steers the interaction in a healthy direction, and keeps everything civil and open.

We only have one chance to make a first impression. We might as well set the tone we want for future interactions.

Technology agnostic

When I discovered the Go programming language it just felt right to me. I felt like I had come home after a lifetime in the desert.

I used Go to rewrite my blog engine. I use it to test new ideas, and to learn new techniques. When working with WordPress I would mistakenly write Go syntax. I want every new project I start to be in Go, and every project I maintain to be ported to Go. Which is a problem for me. I'm turning into a "Go guy"; a language zealot.

I've never been too attached to technology before. Yes, I have my favorites and my preferences. Yes I heckle my friends for their choices; all in good fun I assure you. But I have never decided to use a technology without thinking it through; without evaluating the current situation to see if it is best solution.

I've never been a tool user. I've been a solution finder. What works, what solves the problem at hand, and will continue to work for the foreseeable future. Not every tool or technology will be the best in every situation.

Which brings me back to my current predicament. I must back down from the extremism and fandom. I must temper my affection for Go with the reality of situations. Step away from Go as default but keep it as a tool in my toolbox.

Golang: Crypto sign cookies for security

You can improve the security of your Go web application by cryptographically signing cookies using sugarcookie. A small library used to for signing cookie values that you can verify and trust on a user's return visit. This gives you strong trust and allows you to decouple the cookie from a session on a specific server.

The signed cookie consists of a a secret value, a timestamp, and a unique identifier; which is one-way hashed, then concatenated with the timestam and unique identifer. Then everything is base64 encoded making it suitable for storing in a cookie.

hash := sha256.Sum256([]byte(secret + strconv.FormatInt(t, 10) + uniqueUserId))
value := hex.EncodeToString(hash[:]) + "-" + strconv.FormatInt(t, 10) + "-" + uniqueUserId
signature := base64.StdEncoding.EncodeToString([]byte(value))

You verify the cookie is valid by replaying the hash with the secret and the supplied timestamp and unique ID.

Including the time as part of the hash means you can use it as a secondary mechanism to invalidate the cookie. If it's too old, maybe an half an hour, you know it's no longer good, no need to test it; just invalidate it.

Quitting Feedly, One cut too many

Death of a thousand cuts, simple and deadly. The victim is bound and cut slowly, with small cuts. It's excruciatingly painful and takes a long time for the victim to die. The torture is far removed from our civil society, and it maybe crass to use to describe such, but it fits. Using tools and services we make decisions about what to use and when. It's a balancing act between the service provider asking too much versus what we give up.

So it is with Feedly. They are taking too much, throwing our relationship out of balance. I signed up for Feedly after Google Reader shut down. I gave it a shot because of it's good cross platform support, and the ability to add feeds in the app on my phone.

Feedly has done a couple of shady stuff in the past, but it wasn't so much to push me off. But they're at it again, finding new ways to capture page views at the expense of the original publisher. And this time I'm ready to move on.

It might be that their service can't survive without the click-jacking, but them maybe it shouldn't exist. So, while I don't pay for the service, I'm doing the only moral thing I can, canceling my account and moving onto a different services.

Go Workflow

diagram on graph paper
Photo from Luismi Cavallé

My web development workflow in Go is not much different than how I used to work with PHP, but it is slowly shifting in subtle ways.

When I first started learning how to program, using PHP years ago, I would work in short feedback loops. I would hit F5 to refresh my work all the time. Often with the smallest change I would refresh just to see what would happen. Such a short feedback loop helped me learn specifically what each little change would do and how it would affect my website. As I progressed in learning I would code longer between F5 refreshes.

In PHP I work in a short feedback loop. I look at the outcome requirements and I plan a way to get there. What code will I have to update, what new code will I have to write, and how will they interact. For larger blocks of code I plan how to modularize them, what are the inputs and outputs, then I code up a working example as fast as possible.

Once any new business logic code has been completed I wire it into the front end. I code, tweak and adjust, then F5 to see my website updates. I love seeing how my application shifts and morphs as I refresh and refresh as I update code. The short feedback cycle helps guide me. The positive and negative emotions I feel as things start to work or fail to act nudges me ever so slightly in the right direction.

With Go my feedback loop isn't too different. I develop using vim and tmux. I keep my compile and run command in window 0 and edit code in the rest. I have apache setup to proxy non-existing requests to localhost, where my Go binary is listening. DEV listens on a different port than LIVE.

With Go I have the same requirements process as with PHP. I start coding on the core functionality that is changing the most. Then I move onto wiring it into the existing functionality.

I don't refresh in Go as often as I do with PHP, but it's just about as easy. I switch to tmux window 0, ^C to kill my running process, then go install, and run the new binary. Then F5 in my browser and I'm looking at my updated changes.

Most of the time Go is done compiling by the time I switch to my browser and before I even have a chance to refresh.

The feedback loop is not much longer than when using PHP. There is the extra step to kill and recompile the binary, but doesn't slow me down. Which is then why I find it curious that I find myself using this refresh/feedback loop less and less. With Go I find that I plan more and wait longer between feedback refreshes. There are also times when all the feedback I want is to see if the binary will compile.

The similarities in feedback loop between Go and PHP helped me become comfortable with learning Go. I was able to see my changes as fast as I had before, which helped me learn the eccentricities of Go. Without having to greatly modify my development process I was able to learn Go.