Notes from DDD
The most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user, the business logic or business rules.
The first recursive function I’ve ever really understood.
In JavaScript
var printDots = function(n) {
if(n===0) { // terminating condition
return ""; // terminating value
} else {
return "."+printDots(n-1); // method of construction
}
}
All new section on CSS architecture
I’ve been asked by friends about OOCS, to explain it, also SMACSS -> the two have their similarities.
I like to understand things in a principled way, I like diagrams, I sort of like set-theory – I was wondering to myself if I can at least try to understand CSS in a principled way, using set theory (and diagrams). This is my thinking so far.
CSS syntax, according to the WC3 is ‘a series of qualified rules’ – and a qualified rule ‘has a prelude consisting of a list of component values, and a block consisting of a simple {} block’
for example
prelude {}
The WC3 spec goes on to say –> “Note: Most qualified rules will be style rules, where the prelude is a selector [SELECT] and the block a list of declarations.”
Now this is as far down the WC3 rabbit hole I’m going to go for now. This is all we need for our basic set-theory analysis.
the prelude, or selector, can be thought of as a pointer or label, an abstraction which represents the SET of declarations, they also represent an INTERFACE to the style-sheet, as they are the only public hooks to the style declarations within the style-sheet.
The CSS can be said to ‘export an interface’ in the same way that a C library exports an interface, or a PHP5 object exports an interface (it’s public methods) through these PRELUDES.
The list of declarations within the {} really do have a lot of similarities with a mathematical set, for example if you wrote :
S is a set consisting of {1,2,2,3,4,5,6,6}
the resulting set would be {1,2,3,4,5,6} since repeating elements are not allowed in a set – such things ARE allowed in sequence, e.g. S is a sequence consisting of [1,2,2,3,4,5,6,6] would really be a case of ‘what you see is what you get’
in a similar way the list of declarations only allows one property declaration per type (for obvious reasons) e.g. {float:left; margin: 0; float:right} is {margin:0; float:right} -> the property declaration lexically ‘last’ (in the left to right, top to bottom regular way) overrides the earlier one.
So we have a collection of ‘sets of property declarations’ which have labels that point to each sets.
css represented as sets
The labels interact with your HTML code, ultimately determining what set of styles get applied to what HTML element.
There is a hierarchy of selectors, this is called ‘selector specificity’ – this ultimately determines the precedence of the final set. For example <h1 class=”shiny-heading”> will attempt to apply all the styles pointed to by the label h1, and all the styles pointed to by the label .shiny-heading.
In this case h1 styles are prefered over .shiny-heading, but if there are rules in .shiny-heading not overwritten in h1, they will be applied. This is the ‘cascade’ which gives rise to the name ‘cascading style sheets’.
Specificity rules can combine to make quite a complex an unpredictable ‘interface’ to the sets of styles, which is why, aside from in a basic ‘reset’ style sheet both SMACSS and OOCS generally tell you to stick to classes as the main way of creating your style-sheets API – unlike in Marxism, in CSS all classes are all equal.
This specificity not to be confused with inheritance, which is where child elements of a element in the DOM (e.g. <p> inside <div>) inherit styles, that is something different.
Confusingly, it’s classes and inheritence of a different kind that I now want to talk about – and that’s the inheritance of classes in object oriented languages.
OOP languages can be thought of as sets – sets of methods and properies, usually pointed to by an instance variable.
e.g.
ListMaker bob = new ListMaker();
will create a set of properties and methods pointed to by the variable bob.
So here we start to see the similarities between OOCSS and OOP – I’ve read many rants online that it’s a crime against acronyms to regard CSS as in any way ‘Object Oriented’ but I hope you can see that with the right paradigm, it really can be – no one ever said ‘it has all the features of an object oriented language’ just that it can be seen as ‘object like’ thus, object oriented.
The powerful idea in both OOP and OOCS is to reduce redundancy by designing re-uable functional units, in the case of OOP reusable units of program, in OOCSS case reusable units of visual design.
In order to create good code in a OO language, object types (different sets – called ‘classes’) must be identified prior to coding in an analysis phase, during this phase (in theory although often not in practice!) all the different kinds of objects (classes) are identified and their functions and data are determined, the analysis phase ends and a construction phase begins, this is the first iteration (in an agile style development lifecycle) – often this process reveals short-comings in the analysis phase, so a with that new information a second analysis phase happens, and the objects types are modified, new objects types are created and old ones modified or deleted altogether. Then construction begins again. The point to note here is that object types are not elucidated during construction, you must revisit analysis to create/modify/delete objects.
OOCS and SMACSS have a similar methodology, you don’t simply throw your CSS object types together, you need to carefully analyse your design, and elucidate what ‘sets of styles’ you can see repeating in the design, for example, in Nicole Sullivan’s analysis of Facebook’s design she found 1000s of occurrences of what she called a ‘media object’ a two column block, the left column is always an image, the right column can be anything, including another media object – they can be any size, but they all shared this 2 column image on the left pattern, which can be described in CSS, no point in continually adding the rules for that in lots of different places, just create a set containing those rules and apply it wherever you want ‘2 columns with an image on the left’ – of course you can mis-apply this to the wrong kind of HTML elements, it’s not magical, but she found it massively reduced duplicate style declarations in the CSS. There’s a youtube presentation about it called ‘top 5 mistakes of massive CSS’
So finally I want to mention OO inheritence. Using set theory diagrams lets look at a class->subclass relationship in OOP of ‘mammal’ class and ‘dog’ class.
OOP classes as a venn diagram
Here we see that mammal class contains the dog class. the dog class in fact ‘redifnes’ an area of the mammal class, it can, and often does (although not shown in this diagram) extend the mammal class also.
The dog however, basically remains a mammal, because of the way OO languages treat the inheritence relationship, any functionality not provided by objects of type dog are delegated to the ‘super’ object of type ‘mammal’.
This is similar to the way ‘sets of style declarations’ can be used in CSS, we’ve already spoken of the cascade, if we stick to using classes for defining our sets, the cascade rules are simpler. For example
login-box {
background: grey;
padding: 6px;
border: 1px solid black;
width: 25%;
}
can be a set of style rules, and
login-box-small {
width:15%;
}
can be another set. However, when applied to a html element:
<div class="login-box">.....</div>
and somewhere else in your site:
<div class="login-box login-box-small">.....</div>
you get begin to use the cascade in a way that mimics at OOP class inheritence way – it’s not as elegant, because there is no way of declaring that login-box-small really is a ‘sub-class’ of ‘login-box’ so both must be specified, but it goes some way to eliminating having to repeat style declarations, and gives you a fairly robust model on which to analyse your design.
In the end you’re declaring sets of styles, and giving them a label. The label is an API which hooks into HTML – the architecture of this API can be made to be reusable, maintainable and cut-down on excess duplication, but this means designing the CSS by analysing your design, similar to the way OOP works.
Well, it’s the theory. Good luck, let me know how it goes. 🙂
My Masters paper
its flawed I know, but only had 3 weeks to put it together
Compiling to asm.js
Mozilla’s asm.js is very exciting for web game programmers, although it points towards a future where javascript (mainly in the form of asm.js) will be a compilation target for things like games. This is due to the need for the additional typing that needs to be declared. You just can’t add types to javascript without having some kind of compilation step to set up the heap (implemented as typed array buffers in asm.js, lljs etc) – it may be that work to get LLJS to compile into asm.js modules for perforance dependent code mean we (javascript programmers) can still code in javascipt and get the benefits of compiling to asm.js also – and why not? it seems annoying that you have to write in C, a 30 year old language to compile to JavaScript a language which is half that old.
Members of Microsoft’s Typescript seem to think at some point you’ll be able to compile that to asm.js – seems reasonable so the future looks like they’ll be quite a number of languages that compile to asm.js.
swift ide
Its a pretty much full featured IDE for the BBC Micro, by which I mean it runs on win32 but you use it to develop for the BeebEm emulator, writing in basic and 6502 assembler. I think this will help a lot. it doesn’t use bbc assembler but p65 assembler, which is the same pretty much except how you define constants and the use of the $ sign to denote hex values. there is a couple of hours of tutorial videos on Swift and some links which explain the p65 project.
leave a comment