You might have heard all about frontend devs and UX-designers, but have you heard about those that are practically both? The ones who are into both interactions and code? No, not mutants, but hybrids! Like the ones on the frontend team who think that designing and developing an interface are two sides of the same coin.

Total service stops are rare but happen to every system at some point – it’s just not possible to control every variable in the universe. What is possible though, is handling such situations in ways that leave a somewhat better impression by responding to the rapid change in information needs. That’s why we use failures not only to develop even better systems but also to improve our communication. The following guidelines and examples are intended to help relieve customer support and make customers as happy as they can be, considering the circumstances.

Shipping Guide is one of our oldest applications. As part of a large internal project we knew we were going to do quite a few changes to it. The project was born on the 26th of September 2008. Since then 91 people have worked on the project, contributing 17863 commits to the master branch. Our team did not have much experience with the project and making large changes across the codebase seemed like a daunting task.

Since many of our applications are continuously being upgraded to latest java versions, most of us may have already installed jenv command line tool. But, does it really work the way it should for you? Or, are you struggling to understand or configure it the right way? Background jenv is a cool tool that helps you switch between different java versions in your development machine. But unfortunately, the documentation in http://www.jenv.be/ is not proper to help you with the setup. There’s something more you need to do to make it work properly. This blog is for the newbies who are trying out jenv for the first time or for those who still couldn’t get it working properly.

Do you ever find yourself having to build user interfaces for web applications without an interaction designer or UI developer in sight? What on earth is a fullstack-ish backender supposed to do?! The UXers are off gathering insights, graphic designers are in a different corporate silo all together, the nearest frontender is busy. Fear not! While design work sounds like a scary slippery slope away from coding, there is great pleasure in actually coding the right stuff. There are things you can do to figure out what that is, and DIY till your department hires more frontenders.

We run many micro-services based on java, j2ee technologies and usually try to keep up with all the updates coming in on a day to day basis in the technologies so when java9 was announced we thought that “Hmmm… that’s new”. It was the first java release that wasn’t backward compatible, came with a declaration that it will surely break all our environments and would need time and effort to solve it. We took it as a challenge and thought that we will sail through it easy, but trust me we were wrong.

The following writeup is the story of a fairly exhausting search for a bug in Mybring, that we encountered because we thought that the now 7 year old websocket standard would be safe to use. It’s a fairly comprehensive writeup that covers a few hectic days in January where we got familiar with the RFC, how the http-websocket upgrade handshake works, driving to a customer in order to debug the problem on-site with wireshark and lots of trial and error. The short summary is that if you have customers with “very secure” corporate networks, you need to be very careful about relying on websockets to work. The long story follows here – if you prefer the condensed version, there’s a list of learning points at the very end of the text.

Sometimes it’s fun to take a break and look back at what’s happened in the past and do a little reflection. Or maybe we just think numbers are fun – there’s probably a reason why we like computers! So today we have sat down and looked at the recent past to try to find some interesting numbers. Everyone knows there’s strength in numbers, so here we go!

There’s a saying that goes “an ounce of prevention is worth a pound of cure”. As a software developer, I definitely prefer being able to anticipate and prevent problems rather than stressfully fixing broken systems. Frequently when something in a computer goes haywire, it’s because it ran out of something important, like database connections, disk space, inodes, file descriptors or kernel magicians. Of these resources, the ones that are easy to monitor usually have some sort of threshold-alerts in order to get ahead of the problems.

We really like an idea that the team at Government Digital Service (GDS) wrote about last year in a blogpost: It’s ok to say what’s ok. 🙌 Maybe we just need to say what’s ok. To be explicit about the things that those of us who have been here a few years take for granted. So our team wrote a list of things it’s ok to do at GDS.

There is a lot of value in automation and providing software developers with scripts that can perform common tasks. To get good adoption and awareness of a suite of scripts, it is very important to provide a nice user experience. Just like in frontend, there’s a lot to be said for making things consistent. Little things, like using flags in a manner that is consistent with other command line interfaces matter quite a lot. For example, -v should usually mean the same thing as --verbose. Consistency within a suite of scripts is also important, because it empowers the user – by learning how a feature works in one script, they can transfer that knowledge and reuse it in a different context or script.

Can a design system for the Norwegian postal service be open source? Can the GitHub repo be public? YES! We think that would be awesome. But we work in a large organisation… And while rogue dev teams may be happy to open source — it’s understandable if other departments around us are not equally familiar with the idea. So we wrote up the benefits, showed that we have considered risks and concerns — and found cool examples of other companies doing the same as we want to do.