WSL Tips: Using Docking for Windows inside Bash

This tip is actually really easy, because everything works mostly the right way already. You just need to get the Windows docker command executable from inside Bash. This tip is less “how to do this thing?” and more “you can do this thing!”

First, if you haven’t already, you should go install Docker for Windows, of course.

The installer will let you chose between “Linux Containers” and “Windows Containers” and if you’ll want to select Linux. After the install is done, it will prompt a reboot. Depending on your existing system settings (if you haven’t got Hyper-V already enabled) it might require two reboots.

Simple setup an alias in your .bash_profile  to easily invoke the docker client.

And… that’s pretty much it. You can now invoke Docker from both Windows and Linux shells interacting weith the same sets of downloaded images and running containers. The interoperability is pretty transparent. As an example, here’s a snapshot of my experiment grabbing a Postgres image from the Windows side and running it from the Linux side:

WSL Tips: Starting Linux Background Services on Windows Login

More and more developers are finding out that the Windows Subsystem for Linux (WSL) is pretty great. Being able to transparently use a ton of established *nix tooling on Windows can make your machine a kind of best-of-both hybrid as both a user and a developer.

Updates to WSL have included adding support for background tasks when all your Linux console windows are closed, where previously the WSL processes had to be running under a live shell. However, you still needed to start those services yourself because Linux sessions could only be initiated explicitly. There was no start-up config to launch services like Postgresql or RabbitMQ and the like.

After several restarts after which I neglected to start up these services manually I wanted a solution that would get Postgres running in the background in the WSL layer automatically when I started up my machine.

Here’s how you can start WSL background services on Windows login:

First you’ll need a startup script. I called mine start_postgresql.sh  and put it in ~/.local/bin/ . All mine does is start the Postgres service, but you can start as many other services or do as many other start-up time actions as you want.

Of course, running service requires sudo privledges. But, since we need to run this at start-up without interaction and I don’t want to enable password-less sudo… what do we do?

It turns out you can enable password-less sudo for specific commands without enabling the security faults of allowing your user to sudo just anything without any safety check. Open visudo to edit your sudo config:

And then add this line to enable sudo run only this script.

Great! Of course, your name probably isn’t “calvin” like mine. Change that to your own username.

All that’s left to do is get Windows to run this script in the WSL layer when you login. We can use the Task Scheduler to do this, so open the start menu and type “Task Scheduler” to find the application and run it.

Now, click “Task Scheduler Library” on the left and then “Create Task…” on the right to create a new task you can configure to run your script with these steps:

  1. Name the task anything you want, like “Start Postgres”
  2. Under the “Triggers” tab, click “New…” to add a new trigger for this task
  3. In the “Begin the task” dropdown select “At log on”
  4. Select “Any user”
  5. Under the “Actions” tab, click “New…” to add a new action for this task
  6. Pick “Start a program” for the action type and then enter  C:\Windows\System32\bash.exe  as the program to run
  7. Finally, as the last and most important step, at “Add arguments (optional)” set this argument string to run the command with: -c "sudo ~/.local/bin/start_postgresql.sh"

That’s all you need. When you log into Windows next this task will be triggered and run your custom script as root and start Postgres and any other services you decide to spin up.

Hopefully this will make developing on Windows with Linux tooling even easier than WSL already does!

Two Weeks Into the New Job: What’s Working and What Isn’t?

This entry is part 4 of 4 in the series Joining Red Hat

Not counting my orientation I’ve now completed two weeks of work in the new job as a Quality Engineer at Red Hat. There’s been adjustment and learning and getting to know a new team and HR paperwork and fun and rough edges.

I think its a good time to take a step back and figure out what’s going well and what isn’t and how to turn some of the later into the former.

So, let’s start with the good. What’s been going well at the new job?

  • The product I’m on the QE team for is built using the back-end and front-end web technologies I’ve been using for a decade in some areas (Django) and at least years in others (React). Without even peering inside this has already given em some insight that’s made the transition and some of testing a lot easier. Familiarity is helpful even when I’m not directly building the product, it turns out.
  • At all levels I’m clearly supported in my transition and see the same support going to other recent additions, so I feel pretty comfortable experimenting and exploring where I feel I need.
  • Respect is going both ways. Even as the New Guy I don’t feel like I can’t speak up to argue against a point. The rest of the team is immediately accepting of my input as if we’d been working together for months. I think that goes both ways, because I definitely need to rely on the assumptions of their knowledge and when I reach out I’m confident of getting what I need.

But, a new job is still a new environment, a new workflow with new expectations, and a differnet technology stack and practice. With all the positives and the remarkably smooth transition there’s still bound to be some rough edges.

  • I’m set in my ways after a decade building the same kind of products with largely the same stacks and teams! The move into a team that uses much  of the same technology also means a move to a team that uses that technology differently. That doesn’t mean wrongly, of course, but I am a developer with strong opinions about the ways I do things. I think there’s more room to push for the cases where I’d like to change something for subjective reasons, but so far I’m still finding the accepted edges around which I can make those pushes.
  • Quality Engineering is a top-down view and I have deeply ingrained experience with a bottom-up view of building software. I’m not yet used to focusing on production and production-like environments rather than light developer environments for my day-to-day work. There’s some overhead involved in essentially a QA role that, as a developer in my previous role, I have really strong urges to strip away. Removing those layers would be a detriment to the whole point of the end-to-end tests we need to do, so I have to fight it.
  • The deep knowledge and established practices of Quality Assurance and Engineering is pretty foreign to me as an explicit pursuit. Sure, I’ve tested my software and I’ve worked with QA professionals. What I lack is a lot of the cultural experience that this niche of the software industry has built up, just like the niches I’ve been a part of in the past. That’s something I can learn from a vast selection of material, but a lot of it will take time to absorb through working with more experienced folks and just gaining my own experience slowly.

Of course, I hope that I can continue to have more of the positive experiences than the negatives experiences. So far, that has absolutely been in the case. I’ve already made good contributions to the work and I’m sure I’m in a positive to do some great work. That’s exciting! I’m not under any illusions that I’m walking in like a rock star. I know there’s an enormous amount I have to learn, but I’m likewise realistic in that I understand my own experience is still bringing a lot to the table.

It feels good to be confident. Is also feels good to have so much to learn.

My Software Job Transition Strategies?

This entry is part 3 of 4 in the series Joining Red Hat

I’ve been spending a good deal of the last two days preparing mentally for starting a whole new challenge as a developer. New things aren’t new to me, but this is different and big enough really call for some Deep Thoughts ™. For one thing, I’ve made a big move from the world of Python web development to totally other Python work and while web development has never been the only thing I do, it has been the only work that paid the bills.

That transition isn’t one that bothers me or daunts me, though. Instead, I’m thinking about transitioning to the scope of the work I’m getting into. For a long time, I juggled multiple clients and client projects every day, so no single project usually took up most of my time. Every developer juggles time through the day, but exactly how that works in each company and on each project varies a lot. I was looking for a place that I could really focus in a way that I haven’t for a long time. I think I found that, but now I have to deal with the consequences.

What exactly happens when a developer experiences a big shift in working scope and all the temporal expectations around the work we do?

One of my concerns making this change is the way I on-board to all the new work when it is something of a shakeup compared to the work I’ve been used to doing. I don’t want my acclimation to get in the way of the first tasks I’m giving or, worse, to get in the way of other people on my team. So that’s the word of the day: acclimation.

I need to focus my first couple days on maximizing my ability to acclimate to new tools, new projects, new workflows, and new teams. Everything is changing all at once and I’m going to have lots of questions and lots of problems I need to reach out to people for, or that will be answered or solved as a natural part of the on-boarding process. If any of that information slips my mind or has to get drilled into me repeatedly before it sticks then I’m taking up more of my time and someone else’s than I need to, so Transition Strategy #1 is that I will Take All The Notes.

 

Notes are only as useful as you can get out of reading them. Every day there’s going to be a running log of the things I learn, the things I try to do, everything I observe. That journal is going to get routinely, through the day, rolled into a living outline of the questions, tasks, and understanding I accumulate over the first few weeks. At any time those notes need to be a snapshot of my brain because it is going to be an overwhelmed brain and it needs all the help it can get.

Of course, those notes are going to be far from perfect. I’m going to make mistakes in them and I’m going to understand things wrong when people explain something new to me, so my notes will reflect mistakes as well as understanding. Transition Strategy #2 is going to be failing as fast as a person, not just a rule for software. I’m going to ask someone early before I waste more time than I should. I’m going to take advantage of the experience and knowledge around me to get up to speed and become valuable as soon as possible. I believe my reaching out as a new team member is a good investment for the team and won’t let things like fear of looking dumb to keep me from getting a helping hand.

With notes and with people I’m going to get a ton of information and I’m going to have a lot of knowledge to sift through. That’s inevitably going to take time no matter how much I try to reduce it, be more efficient, or offset my blundering with careful planning. I’m going to decide that’s okay. It is expected, it’s a normal part of a transition, and I’m not going to get held down further by frustrations that I’m not adjusting fast enough or well enough when I’m really just progressing in a totally expected pace with totally expected problems. Transition Strategy #3 will be patience, both for the time this transition takes and for me to figure it out.

I’m Gonna Hit The Ground Running

This entry is part 2 of 4 in the series Joining Red Hat

I already wrote about leaving Caktus to start a new job at Red Hat and that first day was today. I’ve never really had this kind of new-hire orientation before, having spent all my previous software career as a freelancer and just transitioning from a contractor to employee at my last company. I didn’t know what to expect.

I’ve been thinking a lot about what this transition means for me as a developer, obviously. I’m making than a transition in companies here. I’m moving back to full-time Python work from years as one of those Full-stack web developers. While software always has many moving parts I’m transitioning from an environment with multiple diverse client projects to working on more focused, coherent works to deep dive into. Moving from Ubuntu to Red Hat Enterprise Linux, MacOS to GNOME, thirty coworkers to over 10,000.

So it was time for a change and clearly I decided to just take them all at once. Software development is inherently change and new: by virtue of being built everything you make is new, even if similar to the things that came before it. You always learn something new, even as you grow in the experience you can bring to every new project. I have to ask myself two really important questions about how this is going to work:

  • How can I make all the twelve years of experience I have make me as successful as possible applying it to such a new environment and such new kinds of projects?
  • How can I absorb as much of the new experiences I’m going to have in the next few years and avoid being either overwhelmed or leaving too much on the cutting room floor when adapting that experience into my developer-mind?

There might be good answers to those questions, but I don’t quite have them yet. This is something I’m going to get wrong, but not totally wrong. I’m going to make some mistakes and learn to make some adjustments and I’m not going to be phased when that happens. If I can expect course corrections later, then the best thing I can do now isn’t to decide exactly how I’m going to do great, but to decide how I’m going to keep doing better.

I love software because I love solving problems. Knocking a new job out of the park is just one more problem.

Onward and Forward: I’m at Red Hat now!

This entry is part 1 of 4 in the series Joining Red Hat

I’ve been in development a relatively long time and I like to think I’ve come a long way. My career has included a lot of different kinds of work that I’m proud of and learned so much from. I’ve also spent two-thirds of that time at one great, wonderful place: Caktus Group. The people I’ve worked with have been a privilege and much of the work I’ve done has been so very rewarding.

Nothing lasts forever and I want to continue to grow as a software developer. I’m not going to do that in the same environment at this point in my career or my life. I needed something new! I’ve made the tough decision to leave after nearly eight years.

So, onward and forward to new things! Next week I’m starting a new job at one of the most respected companies in the open source community: Red Hat. I’m sure I’ll bump into a lot of people I know from the years, and I’m going to be getting heavily back to my Python roots in this position so everyone can expect to see me at Python meetups again, probably at PyCon, and actively hacking again on old and new projects on my Github, on the open source work I’ll do at the new gig, and I’ll be certainly doing heavy tech blogging again as I’m finding new and great things to learn every day.

It would be cliche to call this bittersweet, but damn is it accurate.

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck another member of your team who may have lost more time without your advice. You can’t consider only your own time. If the disruption does cost you, it is weighed against your teammate.

When a junior developer disrupts you with a question your support of them is important. They can spend more time stuck than you’d spend to help. Consider how much time you’re actually saving by being interrupted if you include others’ time in that equation. This can lead to a long-term boost for the whole team as they learn from you and others.

In either case you should trust your teammates.

The most common disruption complaint is the “hapless manager” walking over to the in-the-zone programmer for a question. Developers think this yanks her out of a productive state of mind that’s hard to get back to. Do five minute interruptions really cost an hour of productivity? Does it take a long time to get back into a state of mind where you’re productive?

There is an often smug animosity towards non-coders who don’t understand what making software is like. They interrupt us, we like to say, because they don’t understand how a programmer’s mind works. This attitude inflates our perspective of what that interruption costs.

But, our managers want us to work well. Any good manager’s job is to support you in your work. We can communicate when real focus is necessary, but don’t be antagonistic about it. Everyone understands context switching, so include this when discussing schedules and allocation. It should be a part of the process to support the focus you need. Like the developers on your team, your manager needs your attention sometimes. Remember to think about the time of the whole team and project. Don’t think only about your own time.

Remember that the actual act of writing code is only a part of our job. Collaborating with our team and coordinating with our clients and company are just as important. Disruptions from outside the technical team are not taking you away from your work. Those interactions are the work, too!

Interruptions can be irritating but they can also do more good than harm in a cooperating team.

And, sometimes an interruption actually helps you.

Those deep states of mind focused on a problem can feel like an important key to cracking a really hard problem. You just need to dig into the depths of the codebase for three hours to figure out how to solve those really thorny bugs, right? Those deep dives can be fraught with false tunnels and misconceptions along the way. An occasional reset can help a lot! A little interruption of your train of thought means you can look again with fresh eyes.

Opportunities in your work day to take a break from a problem and come back to it later are great. It can be good to have something to take you away from your desk. The truth is that “zone” we’re often in can just as likely see us stuck as it can see us through to a solution. Whether it’s taking a break to attend a meeting or juggling a few projects, something to redirect yourself to gives context switches that can be very helpful. Give developers some options for how to spend their time and give them reasons to break up their day.

A specific interruption can be frustrating but they are not inherently costly to a project. Pay attention to the balance, of course. You have to have a team you can trust, both among technical and non-technical members, too.

So, the next time you gripe about being pulled away from coding, think a little closer about it. Are you putting your team ahead of yourself? Are you giving yourself the breaks you need? Good teams give developers time to focus, but good developers give their teams their attention in return.

I’m Tired of Being Tolerant

There’s a common complaint from conservatives these days trying to turn the fights for tolerance in their favor. The right, they say, is “oppressed” when liberal universities support liberal and leftist ideas, but shut down conservative students. There’s no evidence this actually happens, of course.

 

I’m Tired of Being Tolerant.

 

I don’t care if you’re feelings get hurt when people call out your shit for spouting “one man / one woman” nonsense. There isn’t an ounce of patience in a single bone in my body for white boys scared to lose a culture we stitched together from fragments we plundered the world for. If you try to stand up and claim you’re ideas are being persecuted just because you don’t want trans women to piss in peace, then I’d sooner shove you onto the ground in disgust than listen to a single more word.

 

You are not worth my time.

 

You are not worth my ears.

 

You are not worth membership in society.

 

Liberal ideology has always espoused “tolerance” and I’m fucking tired of it. The underfoot don’t need tolerance, they need acceptance and support and lifted up. If all you can offer a gay man is tolerating his existence your support might as well be meaningless. If you’re just progressive enough not to say the racist shit in your head, you’re still a fucking racist. If you want women and minorities and queers in the workplace but wrinkle you nose at actually trying to be diverse in our hiring, then you should get kicked out the front door. You don’t belong at your job, in your community, or in this country.

 

We’re not going to keep being a place that tolerates those who can only tolerate. Step the fuck up, or step the fuck out.

Respect and Code Reviews

Code Reviews in a development team only function best, or possible at all, when everyone approaches them with respect. That’s something I’ve usually taken for granted because I’ve had the opportunity to work with amazing developers who shine not just in their technical skills but in their interpersonal skills on a team. That isn’t always the case, so I’m going to put into words something that often exists just in assumptions.
You have to respect your code. This is first only because the nature and intent of code reviews are to safeguard the quality of your code, so even having code reviews demonstrates a baseline of respect for that code. But, maybe not everyone on the team has the same level of respect or entered a team with existing review traditions that they aren’t acquainted with.
There can be culture shock when you enter a team that’s really heavy on code reviews, but also if you enter a team or interact with a colleague who doesn’t share that level of respect for the process or the code. This mismatches can lead to conflict, arguments, resentment. They can lead to dwindling code quality and eat at the respect and will the whole team has for adhering to the code review.
Hold fast if a new member joins your team who doesn’t buy into the code review sanctity. They will often take code review feedback personally, and their apparent disregard for your suggestions is easy to take personally, as well. That’s a recipe for bad blood and arguments, so try to defuse it quickly.
This brings us to the next respect you need to have.
You have to respect your teammates. You aren’t a collection of programmers who just happen to be working on your tasks in the same codebase. You don’t function independently within the team but as a unit. Code reviews are one thing we do to guide and enforce that idea.
The respect for your teammates goes both ways during a code review. There is respect from the reviewer to the reviewee, as well as the reviewee to the reviewer.
As a reviewer, your attitude and approach can make or break your colleagues’ respect for the process, the team, and you. There are some easy tips in the feedback you give and especially in how you give it, which can make them easier for both sides.
  • Try to avoid blaming “you” language. Don’t say “You didn’t do this right” when you could say “This would be less likely to break if…”
  • Use “we” language to convey the team ownership of the code. If some code convention wasn’t followed, don’t say “I prefer that you…” or “You incorrectly…”, rather say “We always follow array items with a comma, even the last one.” etc.
  • When using “I” language, use soft phrasing. Don’t say “I need” or “I know”, but “I usually” or “I’ve always found”.
  • Just be respectful and review the code for the team, not against the reviewee.
You have to respect your reviewer. I’ve given most of this advice from the perspective of reviewing code, but this rule is all about having your code reviewed.
The first rule of having your code reviewed is “Don’t take the code review personally”. Your code is not a reflection of you and it is never perfect. Your approaches can be great, but everyone can have valuable feedback. Accept feedback with some empathy and humility.
The second rule of having your code reviewed is “The team reviews your code because the team owns your code.” You do not own your code. Even when you’ve just written it when no one else has touched it yet, even if you put hours of effort and sweat into it. You do not own your code, this bears repeating. So, when your code gets reviewed remember that what eventually ends up in the project has to meet the team’s standards and idiosyncrasies. Often, it is essential that you bend your own preferences. You have to allow the code to work for the whole team, even changing your vision. Our code styles and practice should be in context to the team and project we work in, so don’t be completely tied to one approach, even if it’s your favorite approach.
You have to respect yourself. I’m not to write this without including the respect you need for yourself because the rest of the article was dominated by everyone else. Of course, this can mean a lot of things.
Respect yourself to speak up or push back when feedback you get really is wrong, in your opinion. Make your case strongly, but still keep all the advice above in mind when finally coming to a conclusion.
Respect yourself to be a little dignified responding to code review feedback. Don’t take it personally and look petty. Don’t ignore any bits of the feedback without making a case for why, looking dismissive. Don’t get angry about changing code you really looked and highlight your ego.
Respect yourself enough to look good in your teammates’ eyes at the end of the process so everyone can be happy with what finally goes into the project and shared by the whole team.

An Update on My 2018 Game Making Plans

There’s only a couple of days left in February, so we’re a bit into 2018 and I think that’s a good time to reflect on my plans for the year. I’d rather do this sort of thing a bit into the year when I’ve had enough time for the plans to settle and really feel confident about.

So, here’s the plans.

BIRD COP

This is my “big” plan for the year. BIRD COP is my ambitious-but-doable goal to build a complete and full commercial ready game. I’ve been working on the prototype, and development has been going great. I’m wrapping up some bits of the engine before the month ends and then its on to building out Level 1 content as a demo during March.

BIRD COP: He’s 100% bird and ALL cop.

There’s going to be more about BIRD COP very soon, once the artwork starts getting put on top of the engine for the demo / first level of the game!

LUNAR

Part of BIRD COP is a new approach I have to my tool set and I plan to write more about it soon. This is the engine, code name “Lunar”, that I’m building BIRD COP on top of.

I’ve got a few years of Unity under my belt, but I’ve also really enjoyed the recent projects I’ve done with Lua and the LOVE framework. After struggling to balance the pros and cons between the two, I realized i had a way to get the best of both worlds by embedding Lua into Unity and building out a simplified API, like LOVE.

Lunar is letting me separate “game” code and “engine” code, and that’s helping me focus a lot. This isn’t something I plan to release or anything, its just for me, but I do want to write about the approach and share how its worked out. I expect a few blog posts coming about the work on that part of the project!

LOVE TUTORIALS

I don’t think I’ll give up LOVE entirely. For prototypes and game jams there isn’t much chance that I’ll stop using it. So, don’t worry, the Learning to LOVE series will continue. It can take a good number of hours to write extensive lessons, so they won’t come often, but there will be more.

The next installation is on the way.

Stonebird Games

If you don’t know, my “professional” label for game making is Stonebird Games. Separating myself and this label hasn’t been always clear or easy, so I’ve struggled with that, but I want to have a good name to promote projects like BIRD COP under, so I think Stonebird will see some changes coming soon.

Toys and experiments are cluttering the Stonebird shelves. The games on the current page, or most of them, will be moving to my personal itch page. I’ll probably connect them, but I’m going to make some logical separation between games “ironfroggy” makes and games “Stonebird” makes.

The mobile games I’ve made under the Stonebird game will probably stay.

Potential Mysterious Project

I’ve been toying with ideas for a non-development project on the side, centered around games and/or game making. There are different ways this could manifest, but I’m not sure where its going yet. I’ll be making noise if anything materializes.

Anyway, that’s my rough plans for 2018 and making games. Keep me honest and yell at me if I don’t keep to it, okay?