Quinn Gil

Hmm... Fluent types vs Type Types awaiting vs method As part of the Principle of MicroObjects, Represent ALL Concepts, we still need to manipulate the data; at some point; or pass data to 3rd party libraries as primitives. We need to get the raw

I typically code a lot. With a recent role change, not so much at work. To compensate, because I need to code, I have a side project I'm working on. While working on various aspects of this, I've found a recurring theme. I don't

Uncle Bob has a post on his blog from a while back called "The Dark Path". I've personally had an interesting journey with this post. It's taken another turn as I read about the new programming language "V". Unlike Uncle

I've had this sitting in my queue for over a year. Waiting for some day when I have some thoughts on it. Is today that day... Ehh... Probably not. I'm going to try anyway. I'm writing this the same day I wrote the "

Represent All Concepts Let's continue our exploration of how the MicroObjects technical practices support the principle of representing all concepts that exist in the code as objects in the code. In the last post we covered some benefits of applying the practices for this

Represent All Concepts Let's continue our exploration of how the MicroObjects technical practices support the principle of representing all concepts that exist in the code as objects in the code. In the first post we covered the same practices my hour long presentation covers.

Represent All Concepts Let's continue our exploration of how the MicroObjects technical practices support the principle of representing all concepts that exist in the code as objects in the code. In the last post we covered No Getters / No Setters if Only as a

I had a fantastic chat with a colleague about the MicroObjects technical practices at lunch yesterday. Well... yesterday for writing this. Probably a week ago when it goes live... and no idea how long ago for you reading this. :) She wanted to know more

I presented twice at XP 2019! One of them was about the MicroObjects technical practices. Which was fantastic! It's a great opportunity to share what I've found useful! This post is about the second presentation; the experience report. I promote the MicroObjects technical practices

I met Suzanne Fortman from Cincom at XP2019 and had som great conversations about SmallTalk and the community. I decided to download ObjectStudio to play with the product and maybe actually get to write some smalltalk. The experience was not what I was expecting.

I'm sitting in my hotel room after the [deliver:Agile2019] conference (https://www.agilealliance.org/deliveragile-2019/) which was fantastic. I highly recommend attending it next year. I have a little side project I'm trying to use to learn Azure and Azure Dev Ops. At

This post is absolutely a "I don't have a post" filler post. MicroObjects I'm working on a couple of refactoring "kata" type projects. One is for MicroObejct technical practices. I'm trying to do them all as "FizzBuzz" but.

Quality-wise of this post; not gonna lie - Probably will be low. It's 7am and I'm low on posts. This isn't a bubbling pressing issue on my mind. I don't need to stream my thoughts to work through something... What I do need... is

Simpler code. Don't we all wish the code we deal with could be simple? Simple is hard. Simple is challenging. Simple is complex. A short letter is much harder to write than a long one. Why do you think my blog posts are so

There's a lot of tools that exist to make what developers to easier to do. If it's something we do a lot, we tend to find ways to have something do it for us. I've done it. I'll probably do it again. I built

There's a lot of tools that exist to make what developers to easier to do. If it's something we do a lot, we tend to find ways to have something do it for us. I've done it. I'll probably do it again. I built

I've had a lot of discussions around applying the MicroObject technical practices to legacy code. "These practices are clearly great for new code, but how can we work them into our existing code?" Even if it's not your definition of legacy code;

James Shore has a post, Testing Without Mocks, that I've recently been introduced to. Skimming through the introduction of the post, it looks like the goals of this align well with what MicroObjects give us in terms of testability. I'm going to go through

I have a GitHub project FluentTypes which I've written about before. The goal is to avoid the problems of Primitive Obsession. We want to represent what we're thinking. After working in MicroObjects style and using the style represented by the Fluent Types; I found

The legacy code I'm playing with at work had some nice future proofing. It wasn't quite big design up front, but it was some future proofing. I got some out, but there's still a whole level of abstraction that's pending removal. I'm not here

When refactoring from a large to small API, use interfaces for the new methods, but leave the old public IFF they are well tested. Its not worth re-working all the tests when they're hidden by using the interface This is a short little post

Working in legacy code makes it clear how important refactoring is to maintainability. I'll go so far with the importance of Refactoring to say, "If the code isn't refactored, it isn't maintainable." Clearly I think this is a huge thing. One of

What is a DataBag? I consider a databag any object that primarily acts as transportation for data. In C++, this would be a struct. Ignoring any associated functions, the data's exposed and being passed around. Java would represent a databag by a class with

This is me going through the Android recommendations on how to do databinding. As with A LOT of practices that increase the complexity and harm maintainability; databinding and the recommendations enable, perceived, QUICK development, but it has such a high cost afterwards; there WILL