Chocolatey is attempting to be an package manager for Windows. Like apt and yum. I love the idea. The execution thus far has been fairly disappointing. I would love to be able to issue a single update to upgrade the tools I use. Unfortunately this isn't always so easy with Chocolately.
The main problems is a lot of abandoned packages and simply not being as reliable as Apt. Maybe the one impressive thing is that is seems to play nicer with applications installed outside of the package manager, not great, but less terrible. So tools that auto-update might cause problems. And you probably want to keep track of software you are managing a package with Chocolately or not. Which can be even more annoying.
The abandoned and out-of-date packages is not really a problem with the tool itself, but the management and cultivation of packages and people to maintain them. You can't solve the problem of volunteers, but it would be nice if there was a review process which tagged packages that were out of date. It could also use some improvement to how it interacts with software installed outside of Chocolatey.
I'm starting to get into .NET development and windows server management. I'd love to have the simplicity of a command line based package-manager for implementing automation and DevOps practices. If not Chocolatey I hope MS will create or endorse and improve a similar tool.
Monday, February 22, 2016
Saturday, January 23, 2016
Build vs Buy vs CQRS/DDD and OOP Common Wistom
I recently watched Greg Young's CQRS/DDD talk thanks to the Clojure Gazette. Even before I finished watching the video I had forwarded it to several people. I lot of it resonated with me. The desires of the business partners vs the "OOP" patterns and thinking that created the systems never seemed to line up.
There were two points Greg made which really stood out to me:
1. DDD is Expensive?
He spoke about DDD being very expensive and only fit for competitive advantage domains with high complexity because of that expense. I'd like to understand is this a Build vs Buy argument? Or DDD vs the popular OOP/CRUD methodologies? Because Build vs Buy I get. For example I agree that it doesn't make sense to custom build a Customer Relation Management (CRM) solution anymore unless there is something different about your sales process that off-the-shelf solutions can't provide. What are about a domain where there isn't an off-the-shelf solution and competitive advantage is arguable at best.
For simple systems with low data volume and low-to-no batch processing I can see how "common wisdom" (Rails, ORMs, JEE, Spring, etc) can seem like the right choice. As Greg said "We'll use X, Y, and Z, now what are we going to build?" is pretty common. Especially for getting it made quickly maybe go-with-what-you-know is the right choice.
I guess I'd just like to understand the cost of doing DDD better and how it compares to popular development.
2. Methods belong on the Data Object?
For a while now I've had a growing opinion that domain objects shouldn't have methods at all. My experiences have almost entirely been modeling inanimate business data. In the real world an insurance policy has no actions of it's own, it is entirely acted upon. The common example of putting a walk() method on a Dog object breaks down. And the actions upon the data change more frequently than the structure of the data.
The way I was taught Object-Oriented Programming seems like a bad fit for modeling a data domain. In my experiences trying to do that has caused more problems than it solves. I've seen it cause poor data store designs in relational databases. It also seems to encourage coupling and conflating of contexts. "We've already got a Policy object and ORM mapping for it, let's just tack this other context onto that." Inheritance often doesn't apply or is misused to once again bind and conflate separate contexts together.
Maybe I've just spent too much time playing around with Clojure and other functional languages.
There were two points Greg made which really stood out to me:
- DDD is really expensive.
- Methods belong on the data object.
1. DDD is Expensive?
He spoke about DDD being very expensive and only fit for competitive advantage domains with high complexity because of that expense. I'd like to understand is this a Build vs Buy argument? Or DDD vs the popular OOP/CRUD methodologies? Because Build vs Buy I get. For example I agree that it doesn't make sense to custom build a Customer Relation Management (CRM) solution anymore unless there is something different about your sales process that off-the-shelf solutions can't provide. What are about a domain where there isn't an off-the-shelf solution and competitive advantage is arguable at best.
For simple systems with low data volume and low-to-no batch processing I can see how "common wisdom" (Rails, ORMs, JEE, Spring, etc) can seem like the right choice. As Greg said "We'll use X, Y, and Z, now what are we going to build?" is pretty common. Especially for getting it made quickly maybe go-with-what-you-know is the right choice.
I guess I'd just like to understand the cost of doing DDD better and how it compares to popular development.
2. Methods belong on the Data Object?
For a while now I've had a growing opinion that domain objects shouldn't have methods at all. My experiences have almost entirely been modeling inanimate business data. In the real world an insurance policy has no actions of it's own, it is entirely acted upon. The common example of putting a walk() method on a Dog object breaks down. And the actions upon the data change more frequently than the structure of the data.
The way I was taught Object-Oriented Programming seems like a bad fit for modeling a data domain. In my experiences trying to do that has caused more problems than it solves. I've seen it cause poor data store designs in relational databases. It also seems to encourage coupling and conflating of contexts. "We've already got a Policy object and ORM mapping for it, let's just tack this other context onto that." Inheritance often doesn't apply or is misused to once again bind and conflate separate contexts together.
Maybe I've just spent too much time playing around with Clojure and other functional languages.
Tuesday, March 19, 2013
Scala for the Impatient
I guess I'm pretty impatient. I do have a hard time getting through long winded books about languages, APIs, or tools. I want to get in there and start playing with it. Letting my brain leap forward with "I wonder how you do x?" questions. Maybe the book will cover it later, but it is much more fulfilling to figure it out on my own and then compare my way to what the book states.
Cay Horstmann's book Scala for the Impatient has so far been the perfect book for me. The most enjoyable programming book I can recall having ever picked up. I'm not going through it very quickly, but I am spending a lot of time writing Scala while going through the exercises and playing with the language.
As I work through the exercises I'm putting my answers on github.
Cay Horstmann's book Scala for the Impatient has so far been the perfect book for me. The most enjoyable programming book I can recall having ever picked up. I'm not going through it very quickly, but I am spending a lot of time writing Scala while going through the exercises and playing with the language.
As I work through the exercises I'm putting my answers on github.
Getting Started
I am a software developer. Which means I should be on constant journey for new knowledge. This blog is the start of documenting where I'm at on the journey, what I'm learning, and what I'm thinking about.
Subscribe to:
Posts (Atom)