Those icons are absolutely horrible. They are images, distracting the viewer by the amount of details. Icons should convey only the bare minimum of shape. The metaphor of the meaning should be captured, not the incredilous picture of a remotely possible parrallell.
Do you have a point to make or is is this a display of faux-superiority from someone who actually hasn't got anything to say or any way to back up their insinuations? And you don't know what irony means either.
Empirical results are ambiguous, mostly pointing in the direction that there is no difference in readability between serif and sans serif fonts – and those are often very old studies, done on very old hardware with very low resolutions.
As should be obvious from the Website, iA are also huge fans of and advocates for large font sizes, in this case their body text is over 20 pixels in size. Any aesthetic issues (smushed and blurry serifs) are not really a problem at that size. 10 pixel Times might look ugly (even though it might be as readable as 10 pixel Arial) – its details a blurry mess – but if there are more pixels to work with that’s no problem – especially not with that many more pixels.
Looking at the font, it’s also obvious that it’s supposed to work at the still relatively common low resolutions of, say, laptop screens. Its shapes are relatively simple, the amount of detail is relatively low. It’s only a small step up from the very simple (and also gorgeous) Georgia.
Because of the aforementioned aesthetic problems with serif fonts (blurry serifs at small sizes on low resolution displays) not using a serif font might be a good rule of thumb if you are clueless about typography, but it doesn’t make any sense to adhere to that if you actually know your way around.
And even if you are clueless there is nothing wrong with using something simple and very optimized (also beautiful) like Georgia.
I placed the 2010 Dutch Pirate Party (Piratenpartij) election program on Github. I try to elad by example: Set the example by the "internet party", then hopefully others copy & paste it.
There does not need to be any knowledge of _any_ class. A factory method _still_ needs a class instance, you don't need them with factory constructors.
A classical, say Java or C# way will still need coupling to such a class. In dart, there is real decoupling going on.
Uh no it does not, it just needs a class. Unless what you mean by "a class instance" is "a class object". A factory method is a classmethod, not an instancemethod.
A factory method and a "factory constructor" need exactly the same thing: the class object.
> In dart, there is real decoupling going on.
In dart, there's mostly a bloody mess of 4 different constructors when all you need is a constructor and an initializer, as done in e.g. Ruby or Python. And these can be "regular" methods (respectively on the class and on the instance).
Conversely, you can also have an "overridden" constructor as in Javascript: an instance is built, the constructor function is called using the instance as its context, and if the constructor returns something that something is returned by `new` in stead of the original object.
> A factory method is a classmethod, not an instancemethod.
This completely depends on your implementation. It's possible to implement it as instance method, or static method.
> Uh no it does not, it just needs a class.
Whether it be a static factory method or an instance method, fact is you need a reference to an implementation (class). In dart, you can do
List someListInstance = new List();
where List is an interface. There is none class needed in your consuming code, none. In C# or Java, this is impossible: You need _some_ class (whether it be a static method on it, or an instance method) to get a new instance of the interface.
Named constructors felt very liberating when working with Dart.
new List.from([instance1, instance1]);
delivers a lot of clarity, while offering the promised decoupling by the GoF:
> Define an interface for creating an object, but let the classes which implement the interface decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses.
> It's possible to implement it as instance method
It makes no sense, if you're doing that you've switched to full-blown factories (abstracts or builders), you're not using factory methods anymore.
> Whether it be a static factory method or an instance method, fact is you need a reference to an implementation (class). In dart, you can do
> List someListInstance = new List();
> where List is an interface. There is none class needed in your consuming code, none.
That's got nothing to do with factories, or interfaces.
> You need _some_ class (whether it be a static method on it, or an instance method) to get a new instance of the interface.
You always need a class, even in Dart there has to be a default List implementation of some sort which can be called (and has to be specified on the interface, it's not like you can even provide your own default implementation of a third party's interface). As to the calling code needing to know about that one concrete implementation:
abstract class Foo {
public static Foo foo() {
return new FooImpl();
}
public abstract void printFoo();
}
class FooImpl extends Foo {
public void printFoo() {
System.out.println("I am FooImpl");
}
}
class Main {
public static void main(String[] args) {
Foo foo = Foo.foo();
foo.printFoo();
}
}
Oh look at that, the calling code does not know anything about FooImpl.
> Named constructors felt very liberating when working with Dart.
Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.
> You always need a class
Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from, as you confirm later on:
> As to the calling code needing to know about that one concrete implementation:
My personal feeling of liberation comes from the fact that the code is simpler and more clear. The non-coupling is nice, but can be achieved with dependency injection too: the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.
> Your consuming code is tied to Foo. In dart, the consuming code only needs tying up to the interface.
Foo is an abstract class, which is the exact same thing.
> Nope. That's the whole point which I am trying to communicate: you do not need a reference to a class to get the instance of the interface from
Neither do you in the code I posted, can you bloody read?
> My personal feeling of liberation comes from the fact that the code is simpler and more clear.
You'll have to give actual examples of that, because I've not seen it so far.
> the point is the transfer of characters into a mental model which is more efficient with the named constructors/factory constructors.
This phrase doesn't even make sense, what "transfer of characters" are you talking about, and how is it more efficient for the user to type more? (named constructors only add ceremony to factory methods) (I'm not even going to talk about factory constructors again, they're a band-aid on the self-inflicted wound of stupid java-style constructors)
The AGPL licence and requirement for contributor licensing agreements means they can prevent people from making closed-source extensions (like for example if you wanted to tie it into your own internal authentication system), UNLESS you are willing to pay them to license it to you under a dual license.
Can they do that? The "Limitations on Diaspora, Inc." section of the contributor agreement says:
> Diaspora, Inc. will not distribute your Contribution to any third party under any license without also requiring that third party to also make your Contribution available to the public under the same license.
I'm not sure but it sounds like that might prevent them from closed-source dual-licensing arrangements. I suppose that doesn't preclude them from building their own proprietary extensions to the Diaspora software for their own hosted services, although the agreement also states:
> Diaspora, Inc. will distribute the Diaspora™ Software, as a whole, under version 3 or later of the AGPL.
If extensions are considered part of the software "as a whole" then they might not even be able to do that.
If the producer would share the design of the iron with the world, the risk would be reduced significantly. The leftover parts could be identified by crowdsourced databases as nonimportant, or as risky to leave out.
> The leftover parts could be identified by crowdsourced databases as nonimportant
In a low-margin business such as home appliances, I'm willing to bet every single part's cost/benefit ratio is carefully examined by experts before being added.
There's always going to be some parts that are just the difference between good and better (or perhaps bad and less bad) rather than working and non-working. For example in an iron that can spray water there could be a piece that breaks up the water into a wider spray rather than a solid squirt.
