volcanicpillar_crop

New around the web: The Perfect Company and A Little Architecture

This came up in my Twitter, and I’ve never read the blog before, but the post is a good one.

Whatever you do, do not join a company that values something you don’t believe in. Don’t fool yourself into thinking you can change it, or that you can adjust to it. It’s going to suck.

http://blog.capwatkins.com/the-perfect-company

And then, a new one from Uncle Bob:

Woe is the architect who prematurely decides on a database, and then finds that flat files would have been sufficient.
Woe is the architect who prematurely decides upon a web-server, only to find that all the team really needed was a simple socket interface.
Woe is the team whose architects prematurely impose a framework upon them, only to find that the framework provides powers they don’t need and adds constraints they can’t live with.

http://blog.cleancoder.com/uncle-bob/2016/01/04/ALittleArchitecture.html

Is business logic hiding in your data?

Databases are for data. Business logic is usually best stored in readable code. The main reason that it is not a good idea to store business logic in the database is that databases resist change, and business logic changes all the time. A good programming language coupled with a well-engineered application design allows a lot of flexibility for that change to happen on top of the database.

56021_peek-window_sm Continue reading “Is business logic hiding in your data?”

Builder (97) Design Pattern, Part 3

Catching up
Builder (97) Design Pattern, Part 1 has an introduction to the “Gang of Four” Design Patterns book and gives an example where the builder pattern may be useful. Builder (97) Design Pattern, Part 2 talks more in-depth about different ways to approach a common problem in web development, form validation, and ends with a wish for client code that looks a particular way. Namely:

Continue reading “Builder (97) Design Pattern, Part 3”

Builder (97) Design Pattern, Part 2

Builder (97) Design Pattern, Part 1 has an introduction to the “Gang of Four” Design Patterns book and gives an example where the builder pattern may be useful. Where I left off, we have a code snippet like this where the “Validator” class and its associated methods (setRequiredFields and validate) don’t yet exist.

The context around this is that we need a flexible way to validate the form. Continue reading “Builder (97) Design Pattern, Part 2”