Development Experience(s)

PANE showed up in my twitter flow today.  Joshua Horowitz ,  a developer and researcher exploring how graphics and interaction can help people understand complex ideas,  ventures into tried-and-discarded trenches and tries a new approach. I'm excited ot see where this will end up!

In order to raise security awareness broadly in our teams (repetition is the mother of learning), I was guided to talk about OWASP 10 to them. Well, reading the cheat sheet, there were stuff in there that I ... just didn't get. So, I consulted our in-house Cloud Security Architect and had him explain things to me, a favour which I thought I'd pay forward. This article, then, will highlight some parts of the top 10 which either was hard to grasp, or where our CSA gave additional insights. A1 Injection Is the posted response still in the encoding you sent out (UTF-8)? Here, what we want to protect ourselves from, is for an attacker to force our poor web server to start spewing out logs due to unhandled exceptions, giving the attacker more information. So, before you even start processing the request - does it have the appropriate encoding? If not, it's appropriate to return 400 Bad Request. We can be unapologetically obtuse here, logging the error on the server side, but

What are the similarities between Formula 1 and DevOps? How is DevOps relevant outside the IT-department? I really appreciated how Donovan explained devops as a transitional approach towards - what is a common phrase around me lately - "Digitalization". Or how "every company is an IT company" in some way or another. I argue that the first 21 minutes is applicable to everyone working in a modern company, or in a company that is modernizing/digitizing  (and thus is not about the product, but the underlying problem it tries to help you solve). Change my mind ;-) 

Patterns and Practices, Stockholm 2018 Introduction These are our best observations when talking to customers in the field. We welcome you to challenge our observations if you have different experiences. We're here, not only to share knowledge, but also to learn from you. In the envelope, there's a sales pitch of how to attend Leap (Jan 28th - Feb 1st 2019). Two tracks: Architecture or Developer. Designing microservices using serverless technology Masashi Narumoto, Principal Program Manager Serverless = Most of the workflow can be done from the client side, accessing APIs. We care, because we don't need to manage servers. If we have peaks and troughs, we don't have to manage scaling. This means that we might experience cost benefit during throughs. SOA vs Microservices - the biggest diference is the goal. In SOA, once you developed one service, everyone was supposed to reuse this service. Web Service (like UDDI) standards supported this. With Micros

A lot of "technical issues" just fall away, once you restructure your service boundaries. Create IDs before creating the object, so that you can communicate it downstream. You can get rich business data from "leftover" data, such as incomplete orders (so that they can improve the purchase process, for example). Consider services cutting through technical boundaries, aligning them with business needs. Consider naming your technical things 'systems'. Adam argues for taking components for multiple services, deploying them together as a technical system. Find service boundaries by looking at transaction scopes - do we update things at the same time, then they belong together. Anti-requirements. Don't look at entity terms, look at interactions. Look at singular fields and Use cases / interactions. If you're thinking "x has a .. ", you are probably having an entity mindset.  Avoid naming things until much later, or name t