Reinventing the Wheel

Most of my very short career was spent reinventing the wheel (alright, I'm cheating, I've been doing that for longer).

And that kicks ass, because today I'm among the best wheel inventors and builders, and I never have to drive a car with octogonal wheels.

So while you spend your time fixing your car due to shock damage, I'm just driving, and driving, and driving.


In other words, don't be so afraid to check the wheel, figure out that it's broken, and fix it. On the long run (that is, as short as my career), it's worth it.

The Retina Bias

It seems most designers have successfully migrated to retina MBP.

Unfortunately it seems some of them have not yet realized that most people don't want to use that computer to surf the web, be it because it runs the crappiest OS of all times, because 2880*1800 is not a logical resolution choice or because it's just very expensive for no good reason.

Here's one example (most websites are like that) of a startup website that suffers from "The Retina Bias"

In Retina resolution:

It's very empty, but then so are most websites on any big screen (from full HD on).

In full HD (the standard for us real tech guys).
You can still see the phone, but the reflection is dead and so is the rest of the page content.

In 1366*768 (the poor man's laptop, pretty much standard as of today). You can guess there's a phone but you have zero idea of the application layout or the rest of the page content.





There are other standard resolutions in between, and all of them will result in a more or less useless combination of waste of space and lots of scrolling. Scrolling is bad. scrolling is ugly and annoying, scrolling hides what you're supposed to be showing to your visitors. IF you absolutely have to scroll, scroll one div, not the whole page. Be sure though that everytime you make someone scroll, a kitten dies.

What you should be doing instead

Basically what I do: avoid scrolling at all costs, try and use more of the page, think about standard resolutions and take the time to make a beautiful design (not like me).

In retina resolution: retina resolution is a bad idea, 4K will be another discussion, until then you can upscale everything with 10 lines of javascript if you want to take them into account (change body font-size) and it will simply look like full HD with more pixels.

In full HD

In 1366*768

In half full HD (windows+left)

On S3 > android > chrome

Sure, this website is ugly, but I'm not the guy who's supposed to have worked on his drawing skills, that's the designer's job.

Like it should be the designer's job to make webpage content usable for people without scrolls and without trouble.

In every example I used chrome without any toolbar, i.e. the thinnest chrome you can ever have and the best screen use possible aside from full-screen which noone uses.

The negative effects of bad webpage sizing are even more visible when you have toolbars, favorite bars, not-chrome or an Apple OS that thinks you shouldn't ever maximize your browser window unless you want to do that manually.

So please all of you MBP-retina-biased designers, design stuff that the world can use, not just people who bought an MBP retina and an iPhone7.

Fight vertical scrolling, kill page scrolling and please don't kill our bandwidth with retina size graphics.

If you want to think Retina, use svg, not huge static files.

Warranty in Europe (and the world): Don't listen to the seller

Today I went to Aldi to get two broken items refunded (both broke in a few months and both of course benefit from the legal two-year warranty).

I got told that:

1. After one month, Aldi doesn't take care of it anymore and you should call the manufacturer
2. Without ticket there will be no refund

I found that rather unlikely to be legal and did a little research...

It so happens that:

1. The warranty is always an obligation of the seller
2. The legal warranty exists even if the ticket is gone, and any way to prove the purchase origin should be accepted in court.

So once again, don't let them tell you you can't.

You CAN send back anything you don't like or don't want anymore within 7 days of delivery if you bought it online (and you should buy online because that warranty doesn't exist with brick&mortar shops).

You ALWAYS have a two-year warranty on new products and one-year on used products when you buy from a company (very important when talking used cars with any dealership, don't accept any less without a big discount).

That warranty is always that company's responsibility, and yours stops at bringing the item back to them (there is a gray area for online purchases, so pick sellers with free returns).



So about that Aldi thing...
1. After two attempts, I got one of the senior staff of the Aldi shop in Rixensart to make a request for a copy of the ticket.
2. After a month or so, I got the ticket ! I then brought that to the shop that told me they weren't allowed to do anything about it.
3. I then contacted their customer service that started asking me for details about that purchase.
4. I reminded them of the law and kindly asked them to respect it.
5. I got ignored.
6. I sent an email, following their return procedure
7. I got ignored.
8. I trashed the stuff and made a note to work harder so that I wouldn't ever consider buying stuff from Aldi ever again.

Vinyl flooring will save your pocket electronics !

True Story Bro !

The meaning of life (42)

The question was: what is the meaning of life, the universe and everything.

The meaning of life for humans is procreation, we exist because our parents procreated.

To procreate is to multiply, the symbol is *.

And the ASCII code for that symbol is 42.


Douglas Adams stated he picked the number at random, so I'll just consider my idea an elegant invention.

Google HTML /CSS Style Guide Review

HTML

? Omit the protocol from embedded resources. 
? Indent by 2 spaces at a time.
? Use only lowercase.
? Remove trailing white spaces.
? Use UTF-8 (no BOM).
? Explain code as needed, where possible.
? Mark todos and action items with TODO.
? Use HTML5.
? Use valid HTML where possible.
? Use HTML according to its purpose.
? Provide alternative contents for multimedia.
? Separate structure from presentation from behavior.
? Do not use entity references.
? Omit optional tags (optional).
? Omit type attributes for style sheets and scripts.
? Use a new line for every block, list, or table element, and indent every such child element.
? When quoting attributes values, use double quotation marks.

In order to remain consistent across all languages and platforms, 4-col tabs should be used.

TODOs have nothing to do in the markup. Task management is a good thing, do it.

Since HTML is bound to be semantically incomplete, a line must be drawn. I draw it after div,p,li,span,a,h1.

Omitting optional tags is murder. One does not simply self-close tags. (optional tags are inconsistent, break XML compatibility and thus many HTML parsing tools, just to save a few characters)

Consistency > all, and if you're going to pick only one quotation style, pick the same for CSS and HTML

CSS

? Use valid CSS where possible.
? Use meaningful or generic ID and class names.
? Use ID and class names that are as short as possible but as long as necessary.
? Avoid qualifying ID and class names with type selectors.
? Use shorthand properties where possible.
? Omit unit specification after “0” values.
? Omit leading “0”s in values.
? Use 3 character hexadecimal notation where possible.
? Prefix selectors with an application-specific prefix (optional).
? Separate words in ID and class names by a hyphen.
? Avoid user agent detection as well as CSS “hacks”—try a different approach first.
? Alphabetize declarations.
? Indent all block content.
? Use a semicolon after every declaration.
? Use a space after a property name’s colon.
? Use a space between the last selector and the declaration block.
? Separate selectors and declarations by new lines.
? Separate rules by new lines.
? Use single quotation marks for attribute selectors and property values.
? Group sections by a section comment (optional).


The only standard that works across everything, from SQL to Shell to any language, is underscores. Since technology is mostly about linking technologies, incompatibility for no reason is unacceptable.

I'll use spaces when I want to. Useless spacing left and right serves no purpose, unless you're using a broken font to edit code with.

Then back to the single/double quotes discussion.

Conclusion

Overall, the google style guide for HTML/CSS is not half-bad, but it makes critical mistakes on the consistency side (underscores, quotation marks and indentation).


I'll finish with their own:

Parting Words

Be consistent.

If you're writing a coding style guideline, focus on consistency above everything else.

REST (for the web), explained and reviewed

REST is about using HTTP features when they exist and serve your purpose.

URI (Uniform  Resource Identifier)

Don't: 

https://www.myapi.com/api/edit/user/3

.../api/read/user/3

.../api/users/frank/user/3

Do:

.../api/user/3

HTTP Methods

Don't:

.../api/user/create

.../api/user/3/edit

.../api/user/3/read

.../api/user/3/delete

Do:

HTTP PUT .../api/user

HTTP POST .../api/user/3

HTTP GET .../api/user/3

HTTP DELETE .../api/user/3

Multilingual content support

We want to keep the URI unique, so:

Don't:

.../api/blog_post/3/fr
.../api/blog_post/3/en

Do:

Use the language header in your GET request:
.../api/blog_post/3

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Hypermedia (HATEOAS)

The idea here is that you wan't to specify all possible actions within the HTTP answer and as Hypertext, rather than have the application generating them based on external (to the request) information.

Don't:

Add a Save button because you just created an edit form.

Do:

Add a Save button because GET: .../api/post/3 contained the information for that, e.g. (in XML for clarity):

<action link='https://www.myapi.com/api/post/3' method='POST' name='Save'>

This is still unclear to me (and it would seem, to everyone who blogs about it), but it may be that the only practical way to implement a so-called "Hypermedia API" is just a plain old website, with API structure and URLs.

Representation

The URI is unique, but the representations are many.

You should specify the representation using Accept headers like so:

Accept: application/json

for standard application requests,

Accept: text/html

for basic/crawler requests, or even

Accept: application/xml

if you have customers with an XML security filter.

Self-Description

The vision is that you should be able to get all the relevant information for API use from the API itself, and the proposed solution is to use media-types for that (application/myapplication+json or application/json;app=myapplication).

I haven't found anything relevant on this topic so far, meaning that while some people have some approaches to the solution, nobody seems to have a standardized clean and simple way to do media-types.

In other words, create your own media-types, stay tuned for news, keep it simple, make sure your own application gets the meta-information from the HTTP response, rather than from your code.

Architecture Constraints

Captain Obvious to the rescue:

Client/Server: the Server only acts as a Server, it does not hold state.

The Server stores no client state (things that can make the application behave differently, outside of session id and authorizations)

Cacheable: do set your cache headers.

Layered System: whatever the infrastructure, the client cannot tell the difference and sees only an endpoint

Code on demand: you can include .js files in your /js directory !

Uniform Interface: keep it standard and simple thanks to the points above.




Ok so now you know what REST is. Time to review the concept:

The good

One of the objectives is to make web services as straightforward and self-descriptive as possible, using existing tools where they fit the bill.

Self-Descriptive services are awesome, and using media types for that sounds like a good idea.

The use of accept headers for language and type concerns sounds better than /en/ although that means changing languages should be made easy (I often edit URLs because the change language mechanism is either dozen-clicks or hard to find).

The bad

While there are enough HTTP methods to handle CRUD, that is not going to be enough for more advanced cases, as e.g. a "report" item, that requires CRUD + Run, making the use of HTTP methods as API methods a source of inconsistency.

Self-Descriptive services are awesome, but the REST architecture does not specify a standard for this, leaving everyone to do different incompatible things.

Because an API is a tunnel for a remote application to call local functions, the approach of Unique Resource Identification through URLs (i.e. /item/id/method)  is a leaky abstraction.

One of the problems is that it results in an Object Oriented API, with a much wider logical map, meaning that you will have a hundred (virtual or not, same problem for clients) create relation methods like object/id/relate/object2/id2 /object/id/relate/object3/id3, etc. instead of the single method approach like relate/object/object2/id/id2.

Another problem is that it implies inconsistency as non-resource methods won't fit in such a schema anyway (such as login, metadata (relations and items, rights) ), a bit like Java needs a container class to define a function.

It could work if you're only writing APIs with basic public resource access, but that isn't generic in any way.

In order to remain consistent, it is thus better to simply avoid the OO/REST API style altogether (unless you still believe in OO).

My Conclusion

REST has some good points and those are likely to be part of any good API architecture.

However, there are too many bad points to consider REST a valid API architecture, and only one practical good point, with Hypermedia that may or may not be a good point, depending on how the alternatives fare.

HATEOAS is a curious idea: on the one hand it means you need two representations for your API (you don't want the HREF overhead in your application), but on the other hand that secondary text/html hypermedia representation could serve API documentation purposes and maybe even crawling purposes.

It seems to me like a Hypermedia API simply means providing an html1.0 presentation for your API with  human-readable documentation associated with its text/html media-types.

It may have value but then they should've just called it that instead of adding more buzzwords.

Links

Concrete Example

REST / Headers

Something on Versioning and Headers

Roy's Thesis

One (imo wrong) way to self-describe