Block category of sites (gaming) at certain times on a Ubiquity USG

I’m writing this as a reminder to myself, but it might also help others since it took me quite some time to figure out all the bits and pieces. It uses DPI (Deep Packet Inspection) to classify network traffic and therefor doesn’t work for everything. For example, it didn’t block Minecraft.

How to

Open a terminal and ssh to controller with username and password that you find under USG Settings -> Site

ssh <username>@192.168.1.1

Enter configuration mode

<username>@ubnt:~$ configure

Save the configuration file

<username>@ubnt:~$ save file

Open another terminal and SFTP to controller

sftp <username>@192.168.1.1

Download file

sftp > get /config file

Open file in text editor which can save with unix line endings, for example Notepad++.

Add

name DPI {
    default-action accept
    rule 10 {
        action drop
        application {
            category Games
        }
        time {
            starttime 09:00:00
            stoptime 14:59:59
            weekdays Mon,Tue,Wed,Thu,Fri
        }
    }
}

(mine is in between “name AUTHORIZED_GUESTS” and “name GUEST_IN”)

Upload the configuration file with SFTP

sftp> put file

It gets uploaded to /home/<username>/

In the first terminal, where you are in configuration mode, load your new file

<username>@ubnt:~$ load /home/<username>/file

Try out the settings by committing the change. Committing means that your config is applied until next reboot.

<username>@ubnt:~$ commit

If it works as intended, save the changes.

<username>@ubnt:~$ save

Resources

To view category for a site

<username>@ubnt:~$ sudo /usr/sbin/ubnt-dpi-util search-app amazon

I followed this guide first to create the rule for blocking according to DPI, then downloaded the config, added the time specifications and then uploaded and applied the modified config.
https://help.ui.com/hc/en-us/articles/218732788-EdgeRouter-Create-a-Firewall-Rule-using-Deep-Packet-Inspection-DPI-

Here is where I found someone adding times
https://community.ui.com/questions/Firewall-source-Mac-address-fails-on-commit/f416b90d-8f71-4c43-8fdc-7afcc92889b8#answer/de3f0b91-9d97-4d48-9d30-95bb03510be0

The mob and frustration

Or “should you split up to work on parallel tasks?” 

We had a few weeks of constantly changing topics. We worked a bit on one thing and then we noticed a warning from one of our systems that something was wrong, we looked into it, changed back to the first thing, had to wait for feedback before we could move on, changed focus onto something else, the feedback came in, we changed back, etc…

All of this happening while we had this rather big undertaking looming in the background on which we worked in between the other tasks. Something important that we need to get done but without being urgent. We need to get to it though, otherwise it will become urgent and then it will be stressful and hard to do a good job with it.

As we realized what was happening, with our collective frustration showing in different way, we sat down and talked about it. We uncover that we’re mostly to blame ourselves since we’re trying to be forthcoming to a lot of different stakeholders but we could actually be better at prioritizing. Since a lot of the things that we have been doing have not been urgent and could have waited a day or two, we could have had more focus on the big undertaking while bundling the odd things up for a particular day.

With the blessing of our Product Owner, we decide to clear this last attention stealer out of the way and then focus on the big undertaking for a week.

Back at the mobstation, we start working and discover that we have two things to do: add a link to the front end and add some css to that link because it shows as white on white background at the moment. We ask ourselves gingerly if we should split up for a while. One person could add the css while the others add the link. It is trivial anyway and we’ll be done quicker. We don’t usually do this but maybe this is a good situation? We really want to feel that we’re making some progress.

Everyone is apprehensive. We’re frustrated and want to move forward. But we also believe in the mob. We believe that speed isn’t the bottleneck. We value sharing knowledge over being uncomfortable.

We decide against.

And run into issues with the simple task of adding css since we’re unfamiliar with the project. And realize that what we thought should be a link would be better as a text. And the text isn’t white, so no need for a special case css.

It feels like staying true to our values was the right thing to do in this situation because it’s hardly never a simple straightforward thing in software development. But was sticks with me most is the realization that even it had been a simple and easy fix, it would have saved us at most 10 minutes.

So it’s either more difficult than you think and then you need the mob. Or it really is that easy but then the gain is minimal. The frustration was hurting so bad, all we wanted was to alleviate the pain and for that we almost made a bad decision.

What I learned from this experience is that for me, it’s not worth it to try to gain a little time by splitting up the mob even it would feel temporarily better.

 

 

Photo by Robert Bye on Unsplash

Running a fully remote unconference

Our 20+ people dev team is a remote friendly (single timezone) workplace with people living in different places in Sweden. We get together once a year for an unconference where you are expected to participate physically but we wanted to meet up once during the autumn as well. Having our weekly meetings fully remote already (we just sit at our desks with headsets if we’re in the office), creating a remote unconference didn’t feel like a huge step.

What is a fully remote/remote only meeting?

This is a meeting where none of the participants are sitting in together in a meeting room. A typical meeting requires booking a room for the onsite people and letting the the others join on video/audio link. Being fully remote evens out the experience for everyone. Having some people in a room always creates a “us and them” feeling if you’re not attending the meeting physically and the remote participants are often an afterthought.

So how was it?

Excellent! It gave me the same energy and inspiration boost as I get from a colocated unconference: problem solving with my colleagues, sharing ideas and finding inspiration. It ran ridiculously smoothly.

How did we do it?

We ran a very lightweight event with 5 lightning talks and 2 open space sessions.

We used a combination of Slack, Skype and Trello.

Trello was used to form the agenda the same way that you would do on a board/wall during a regular open space. Anyone could post a topic and then we organised them in Time slor 1, Time slot 2, etc…

Skype for Business was the equivalent of the main room. The call was activate throughout the entire day and people could join and leave. A skype meeting call doesn’t die when the last person leaves it so it could stay active for the entire time that the meeting is booked in the calendar. It also doesn’t have a upper limit of participants (that we would hit in this context)

Slack was used for the breakout sessions. The person proposing the topic would start a call in Slack named after the topic and people joined the call they were interested in discussing. Slack has a limit of 15 people in a call.

Some tips

Do

• Try to keep video on if possible. It gives you those extra cues to see if someone is just about to say something and makes the connection between individuals stronger.
• Slacks 15 people limit is beneficial in this context. You’ve probably attended an open space which is too large for its own good. This gave a technical limitation. Embrace it!
• A couple of us rounded up the day by playing a little mmorpg together to get some of that atmosphere that you could get from having beers together.
• Remote lightning talks has the benefit of allowing you to keep a script by your side so if you’re want to ease into public speaking, it could be a great warm up step.
  

Don’t

• Have the people in the office sit in a room together. Everyone needs to be at their laptop with their own headset. If your office environment is too noisy for this, encourage people to work from home that day. This evens out the playing field for the regular remoters and teaches the office teammates more about the experience of working remote.
• Do this as your first fully remote meeting. It requires a bit of practice and getting used to, both when it comes to the technical set up and how to behave.

 

Final thoughts

I would definitely recommend this as an alternative to a co-located unconference if you have some people working remotely.This experience was further argument in my book that remote teams can be as successful as colocated teams if you’re willing to let them.

 

For more remote teams thoughts and tips: https://www.remoteonly.org/

X Unit Tests, 0 Integration Tests

Sometimes a gif says more than a thousand words. In this case, what happens when you only focus on unit tests and don’t test anything else?

 

Here is my personal collection of “X unit tests, 0 integration/usability tests”

 

The faucet works, the sink works…

 

 

 

The tunnel works, the truck runs…

 

 

 

The trash can works, the dryer works…

 

And my personal favorite:

 

The lock works!

Remote Mob Programming Set Up

Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time.

A lot of things are being said on the benefits of mob programming and in my opinion they are probably all true. Given a team with similar values and individuals with the ability to put aside their personal preferences in order to move forward* you’ll see interesting results when you adopt it.  Sure, you might feel you’re going slower but you’re being the turtle, not the hare.

I’m not going to dive into the benefits, plenty of people do that. I just want to present my team’s set up for remote mob programming. We’ve had one person permanently remote for the past 3 months and I sometimes call in from home as well. Our team is The Perfect Size of 4.

 

We’ve got a mob station which is an adjustable standing desk, one stationary computer with two monitors, a really good microphone, a headphone splitter, one keyboard and one mouse.

The ergonomics

Having an adjustable desk means that you can switch between sitting and standing. If you have tried standing at work, you’ll know that you’re feeling more awake and that after a while your back will be stronger. We’re happy to have the option to stand while we’re working.

The visual

The monitors are mirroring each other so that it’s easier for everyone to see regardless of where you are standing around the table. There is less of a need to have a huge font size and some programs don’t even give you the option to increase the font size on the menus so having the monitor closer makes it a bit easier.

The coding

We use Teamviewer to share our mob station’s screen and it also lets the remote party have control of the mouse and keyboard. This makes for seamless rotation when switching driver. When you’re the one remote, it’s almost as typing live.

The audio hardware

Our microphone is a Blue Yeti which is a good quality usb microphone. It has a recording pattern which picks up sound primarily from the front of the microphone (and not all the way around) which helps a bit when you’re remote and the rest of the office is chatty.

We used to not use headphones but because of sound quality we would crank up the volume on the speakers to hear the remote party properly and that would disturb the rest of the office. So we wanted to switch to headphones.

In order to do so we started using a headphone splitter which allows us to connect up to five people to the same computer.

The Blue Yeti offers the ability to hook your headphones into the microphone which means that you can hear yourself speak as well.

This is very important because if you’re three people around a table all wearing good headphones, you actually won’t hear what the two others next to you are saying. You’ll only hear the remote party. By hooking in your headphone splitter into the microphone, you’ll hear everyone equally well.

To get this to work, make sure that the Yeti is both the recording device and the audio output in your call settings.

The audio software

Being a .Net shop we’ve switched from Slack to Microsoft Teams :O

It’s working well for us and we create a Teams meeting whenever someone uses the mob station and remote people can join the meeting if they want. It’s basically Skype but embedded in Teams and it does its job.

Summary

It’s taken us some time to find our set up. We started off with working on someone’s machine and each day had a bit of set up time to get things correct. The microphone had to be moved around, etc. Getting the headphone splitter made a huge difference for us (and the office) and getting the mob station also made a big impact.

By now, getting started is quick and easy and being remote for whatever reason isn’t an obstacle for team work.

PS. The Cucumber team is another remote team doing mob programming, here’s a article about their set up: https://cucumber.io/blog/2015/12/21/the-mob-rules-ok

 

*  in one team the first conflict to arise was “-that’s not way you write nice code! – yes, it is! – no, it isn’t! – yes it is!” kindergarten style… and no one budged.

Becoming a modern Renaissance Woman

TIL: my wish to become a programmer stems from wanting to become a renaissance woman in my field.

It’s difficult with all our advances in science to be among the top in many different fields, the same way Laura Bassi did in the 18th century for example. But I think within the field of Software Development it’s (possibly, kind of, for some definition of it) achievable.

Not in the sense that I want to be recognized as the top but I want to understand this field. Like deeply understand.

I already know a great deal about testing and realize that I’m far from knowing it all. I have some awareness of where some of my gaps are. I feel that’s more than I knew when I started out, or a few years ago. Some day I might fill those gaps and probably discover new ones in the process.

I’ve also come to understand and learn about teams and coaching. Here, I’m not as far advanced as I am in testing. It’s an incredibly vast area but barely scraping the surface has given me powerful insights already.

Coming into the world of programming and making (more) sense of how systems programmatically fit together will give me another piece of the puzzle. So far, I’ve been approaching it from the outside perspective. I’ve seen programmers struggle and I’ve helped best I could but I haven’t experienced it first hand. This is of course the most crucial piece of the puzzle since without the act of putting the software together, we’re not doing Software Development.

Not that the software has a raison d’être in itself. If we can solve the problem without software, that’s even better. I just want to contribute when the software is designed to make someone’s life easier. For example, it can be that streaming a movie is easier than going out to rent it or that new entrepreneur can charge for her goods easily.

My best guess is that my journey will take me through a few more different roles within Software Development. Or maybe rather than roles, performing other activities than testing, coding and coaching. It wouldn’t surprise me if I find myself iterating over those activities to deepen my knowledge.

It’s in that sense I see this change of career path as a part of becoming a renaissance woman. Rather than specializing in one or two fields of Software Development, I want to see as many perspectives as I can.

I find myself driven by one main question “how does it all fit together?”

Looking for a programming job

Here is my full resume as PDF: UlrikaMalmgren-Resume
LinkedIn profile
(Unfortunately I’m not interested in consulting, relocating from Stockholm or remote work at this point in my life)

I’m looking for a job as a programmer. Even though I’ve been working with software development for 10 years, I’ve never written production code for money. There has been the occasional helpful tool, automated testing and such but never anything a user has seen. After a year as an agile coach, I’m dying to dive into programming!

(But why? I think partially because of this)

What I’m looking for is a team where I’ll spend most (all?) of my time working together with the team members and where people share my love for quality. I want to spend my time pairing or mob programming. I don’t know what kind of programming I want to do, I’m just ready to explore.

Even though this will be the first time I dive into production code programming, I’m not a Software Development rookie.

What I bring to a Software Development team

• knowledge and understanding about testing. What it is, what it isn’t.
• experience as a team coach
• knowledge and understanding (and love!) of Kanban principles
• problem solving intuition
• pushing on to finish: I have the endurance to get things done. I mean really done with all the details.

I have basic understanding of git, terminals, unit testing, java, python, ruby, cucumber, selenium. This means that I’m able to do some basic programming projects without spending too much time on Stack Overflow. 😉

I feel that my Master of Science in Information Technology studies have helped me reach good intuition about problem solving and troubleshooting which I’ve been developing ever since. I have to be honest, I do love a good troubleshooting from time to time. KTH also boosted my self confidence. After all the operating system, parallel computing and message passing labs, I feel that there is nothing I can’t conquer.

From my time as a tester I’ve learned many ways in which things can go wrong. Testers quickly learn that their work is not done until the i’s are dotted and the t’s are crossed which means that there is no room for sloppy work. You need to fire up IE7 even though no one in their right minds wants to use it.

As team coach, I’ve developed an arsenal of techniques to help a team from slicing work into meaningful pieces to getting to know each other’s personal values. I’ve also experienced what benefits a pull system can bring to a team. I believe these to be helpful for any team.

 

My Software Development values

(If we don’t match in values, there is no point in going further than this)

• one small thing at the time: it’s just better and faster. Not everything can be highest prio.
• get feedback quickly: we need to know if we’re on the right track. Let’s not plan in details too far ahead.
• working together: it’s better for quality and creativity. It’s a waste of time to not pair.
• take time for improvement: you need to carve out time for improvements and use it well. This is as important as features.

 

So there it is: junior developer but senior team member. What do you have for me?

Here is my full resume as PDF: UlrikaMalmgren-Resume

LinkedIn profile

 

 

 

 

How important is writing?

I read this interview with Matt Mullenweg , the creator of WordPess, where he says:

“Skill in writing is one of the things I look for the most in hiring, because I feel that clear writing represents clear thinking, regardless of someone’s background, or whether they’re a designer or coder or whatever.

The ability to communicate effectively and clearly in written form is not only super important in a distributed company, but I think reflects well on how they approach life in general.

Part of the reason I started blogging and started working on WordPress was because I love writing.

If I can become a better writer, perhaps I can become a better thinker.”

I feel that my writing reflects my thinking a lot. I’m a slow writer, an email takes me ages. I pick my words carefully, delete, rewrite and keep going until perfection or until I say to myself “come on, you’re just cancelling your subscription, this is probably good enough”.

I wonder if the process shows in the results. I also wonder how my favourite colleagues do in this regard. Would I have hired them based on their writing?

 

Lightning planning

Some teamwork is better done in silence.

My golden rules for planning:

• I want to spend as little time as possible on the things which don’t matter.
• the goal of planning is deciding what to do, not how to do it

While a planning session can be a drawn out and tough experience with lengthy discussions, I like to keep the planning quick and full of energy and here’s one way of getting there.

Silence

Start by bringing up your work items on a white board or a table. *

Use categories: “do now”, “do later”, “never”, “I have a question before I can decide”

(Regarding the category “never“: some things are not relevant anymore and some you know will never be a high enough prio to make the cut. Just get rid of them, you’ll feel better afterwards.)

Ask participants to move items to  in silence.

If some items move back and forth between the categories, put it in the question category.

After 2-3 minutes you will have a rough filtering of the items without much effort. In my experience, half of the items in our backlog are filtered away.

Put away the “do later” items. Read though the “never” to make sure nothing important gets lost.

Questions and Answers

Now you’re left with the questions and the “do now” items.

Go through the questions (here is where you need to bring your facilitator skills and keep it short. The purpose is to get the question “do now, later or never” answered. Be relentless!

What Now?

So, finally, you’re at “do now”. Figure out how many things you can handle in the time frame until your next planning by using your throughput or velocity.

Now you want to fill those slots. If you have many more possible items than slots, I would try to avoid going through each item on “do now” and discuss them since you want to only discuss the things which you’re actually going to do. We don’t really know for sure which ones those are yet, but we can try to narrow it down.

Here you could use silence again to prioritize from most important to least important by asking participants to move the items in silence. You could also dot vote.

Double check that none of the things which aren’t in your slots is crucial during the time until next planning.

Done!

Why it works

A common mistake is to go through items one by one. There is always something to say about an item even if we agree. Especially if there is a technical challenge in solving it.

By using physical items and silence we enable the team to quickly show consensus on the things which they are in agreement on. We visualize what we need to discuss and what we don’t.

As a former tester, I put a lot of value in discussions regarding work items, the sooner the better. But in this case, I want us to agree upon which need we need to solve first, before we have the discussions on how it’s going to be done. I would say that’s a design discuss, or something for a Three Amigos meeting.

 

 

*if you already have a physical boards, this easy. Otherwise print out your cards and use magnets or write post its for them.

3 ideas to energize your stand up

I already described how using Walk the Board made our stand ups more efficient, here a few more ideas to make them even better.

Have team members take turns to facilitate

To increase the team’s ownership of the stand up (you’re supposed to be doing them as a way to help the team), having team members take turn in facilitating the meeting is a great idea.

Your role when facilitating is to make sure that this meeting brings as much value to the team as possible. It’s good exercise for each team member to reflect upon what that means.

It also livens things up a bit because everyone has different tempo when facilitating.

Furthermore it minimizes the risk that team doesn’t do the stand up when the Scrum Master is away because .

Work with WIP limits

To promote collaboration further and put even more focus on finish things rather than starting new ones, Work In Progress limit (WIP limit) is a great tool.

When there is no more room on the board because we hit a limit, we need to start helping the others out to finish a task or story before starting something new.

Agree on a code word for interrupting discussions

A common problem during stand ups is when a couple of members get involved in a long discussion about for example, design.

One tip to solve this is to agree on a code word to use to cut that discussion short without anyone getting offended. They are welcome to resume the conversation when the stand up is over.

I’ve heard people use SUMO (Shut Up and Move On) and in my team we say “time is like a tree” since we have this motivational poster on our board.

And then…

There are plenty of more ideas to use to improve your stand ups. I’ve heard of drawing a circle on the floor to get team members to stand closer together and other interesting ideas. Dare to explore and don’t just stick with the same formula forever!