Disclaimer: I have not read the DDD bible so my understanding on Entities, Value Objects and Identities is derived from discussions on the web. But since “a rose by any other name smells as sweet” I might be right.
I haven’t got a compeling argument for the necessity of immutability of a request/response object. Still, I really want one and before I ask anybody for one I think I should present my premises for the arguments I made against the immutability. Sometimes we get the wrong conclusion not because the logic is flawed but because the premises are wrong. So, let’s get started.
Most of the articles I’ve read about Entities and Value Objects use a Person as an example of an entity and an Address as an example of a value-object. The reasoning is simple: a person can change its name but still, is the same person while an address that changes its street name is not the same address anymore. Everything is fine until you start to ask some questions. If a person’s birthdate is changed can we still talk about the same person? If an address represents “My home”, changing my home address did nothing to the identity of “My home”.
From my point of view we assign identities to value objects and by that we make them entities. A person is an entity because we decided this apriori based on how we think about the concept of “person”. We know that a person can change it’s name, social security number, parents etc and is still the same person because we recognize it but a different set of characteristics (visual appearance?). There is a mental disorder called prosopagnosia where people cannot recognize the face of other people. For the person that suffers from this disorder each person is a Value Object; person X might have the “proper” attributes but there is no identity associated with that person. One of these people was sure that his wife is an impostor; she looked like his wife but it was not recognized as his wife.
It is we who decide what object has an identity and what doesn’t. Let’s consider an ecommerce website where the user can manage a list of shipping addresses. If I want to the first address of addresses list one can say that I’m creating a new address while removing the old address from the system. On the other hand I am actually editing “the first address on my addresses list” which is… the identity of that address. Whatever changes I make to “the first address on the list”, that address will remain “the first address on my list”.
It is us who determine if an object has an identity or not. And in the case of the request handled by the a web application, the identity of that request is “the request sent by the client”. Just like I can still recognize my mother that suffered changes in name, appearance, age, location, weight and height I can still recognize “the request sent by the client” that moves through the application and was processed by a dispatcher and altered by some middleware, plugins etc. as well as “the response to be sent to the client” to which different components attach and change headers, completely transforming it from the time it was constructed until it reaches the user’s browser.Read More
Responsive design is all the rage these days. No grid system is worthy if it’s not responsive, “mobile-first” is the first thing that experienced designers tell their clients and so on. Recently, Smashing Magazine published an article about “preparing websites for the unexpected” which is just another piece of “responsive propaganda”.
First of all while the article suggests it will teach us to prepare for the unexpected, the only examples include desktop and mobiles. If I recall corectly, responsive design was supposed to solve the problem of tens of different screen-sizes out there, but more an more I read articles that only shows the 2 extreme. I understand that it’s easier to illustrate a point using only 2 examples but if it where to take into consideration only the 2 extremes it would be easier to implement 2 versions of the website, mobile and desktop.
At one point the author suggests, for the sake of the reader, to break long articles into small pieces, for mobile users. Which obviously raises more problem than it solves. How the editor of a website who’s writting an article in an WYSIWYG editor determine the best way to split articles, if it’s so important not to force the user to scroll that much? How is going the article going to be splint on a portrait iPad or Galaxy Note? Does it matter that the user is in landscape or portrait mode? Can anyone imagine adding breaking points in a WordPress post?
In another recent article from Smashing Magazine, we are told about the benefits of the PICTURE tag.
The “Art Direction” use case. Image credit: W3C.
Looks nice doesn’t it? But how would a user know that viewing the “desktop” image on its mobile is wrong? The designer has some knowledge about the technology and can envision a “better” solution, but the user is ignorant about this issues. If it were to really be responsive we would need to account for network speed as well and deliver “not-so-perfect” pictures for people on slow mobile connections. The people I talked to prefer they wait a little more for a “retina-enabled” picture than get an average picture fast. I remember a usability talk where there presenter was baffled when his 50 year old mom was able to adjust to the new Apple mouse (at some point Steve Jobs decided to change the scrolling direction) in a matter of seconds although the usability-minded people where screaming its a bad move.
Most of the time people go with what they receive. Unless they are told otherwise they will not know the difference. There are places where people can learn to spot the differences but not everything is comparable. People can detect if a website is faster or slower than another but they will give the benefit of the doubt in some cases (like people that will accept a slower speed if they see beautiful screens) but you need to think hard about why the story about the President’s dog has a picture where the dog is 20% of the picture and not 100%.
Now, let’s assume for a second that I’m wrong and ponder this question. Who are the people that we are trying so hard for? Do you really want to please people that will flip out if their images on the smart-phones are not properly resized and cropped or that long articles are not split into flippable screen-sized chunks? The road to hell is paved with good intentions. People are starving to death in many places of the world and yet we try to improve the lives of people that change their smartphones every year?Read More
About 1 year ago I came up with an idea for better handling of progressive enhancement and I finally have been convert into a project that I can share with the world.
My solution is about abstracting the way we load the resources required by an enhancement and how we initialize it. Being mainly a server-side developer I’ve written a lot of code like the one below
// and later in the page
This type of coding creates some problems. You cannot easily change the script that makes the enhancement (if you want to use a “lighter” solution for tabs you will to make changes in lots o places) and you cannot reuse the code (for each project you have to write again all those lines).
Once I’ve found out that curl.js and require.js exists my computational machine that I call “the brain”, brought this solution to my attention. I’ve implemented it about 1 year ago but I didn’t have time to make it public (you know… write documentation, make a GitHub repository). It’s available now at Feaxures.com.Read More
Recently I’ve been watching a documentary on how the brain works and how we get a grasp on reality. At one point the presenter said that although we think we see clearly and we believe the image we have on our minds about what is in front of our eyes is clear that is not what the eye actually transmits to the brain. In order to create the crisp image of reality that we enjoy the eye has to move a lot, and fast. The brain gathers lots of tiny snapshots and recomposes them to create on big, sharp image.
The eye sends to the brain images that are crisp in the middle and more and more blurry towards the end. Like this:
This explains why whitespace plays such an important role in web design. Look at the following screenshot from the adevarul.ro website
and how the brain sees it
As a comparison look at bostonglobe.com
and how the brain sees it
I’ve been trying to find a solution for creating fluid grids (and layouts for that matter). The problem with fluid grids is the box model in the browser. When you have fixed-width grids you can easily calculate the right width of a column. But with fluid grids that is not possible (yet). If you set the column width to 25% and you need 2.5% left/right margin the total width of the box will be 30% of the container.
If you try to use negative margins and increase the width of the container (like some fixed-width grids are doing) the browser breaks down. In the example above you’d need to increase the width of the container to 105% and redo the computations for the grid boxes. The grid boxes will have a 2.5% left/right margins and a width of 21.25% (105%/4 – 5%). The math becomes more complicated for 16 column grids or for nested grids. I tried it but the browsers do not behave consistently so, even if you are willing to struggle with the math, I don’t think this is a viable solution.
Stepping back from this problem I realized that the complexity of this problem is generated by the desire to have the left margin of the first column exactly aligned to the left margin of the container and the right margin of the last column exactly aligned to the right margin of the container. But if you stop and think about it, when you want to use a fluid grid/layout you’re not working with a, lets say, 960pixels wide container. So, even if the container is the BODY tag you still need some kind of left/right margin so the content doesn’t touch the margins of the browser window.
Since you must have those margins you can use those margins to help you with the problem. Let’s say, inside the BODY tag, you only have a 4 column fluid grid, each column being 25% in width. That is perfectly possible in any modern browser. Since the first and last columns in the grid must have a left and right margin, so that their content don’t reach the window’s margins, you must make sure that the content of the columns will have left/right margins. That can be achieved easily via CSS using child selectors. All you need to make sure that the columns will have only block-type elements. Which that happens most of the time; there are very few occasions when you have text or inline elements in columns)
This is a WordPress blog and the side bar contains only block type elements with class “widget” and the main area contains only block type elements (headings and divs for the articles) so it’s easy to see how a fluid layout (75% for the main content and 25% for the sidebar) can be achieved on this blog.
The only caveat with this approach is that, since the content of grids will have a left/right margins relative to the grids container you must make sure that the rest of the children of the container must employ the same margins.
But enough with the theoretical mumbo-jumbo. I’ve created a set of LESS mixins that can help you create fluid grid/layouts. Check out the project page.Read More