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

Invisible MMO cell boundaries

Imagine you're flying a space-capable plane, fighting enemies on the ground. (that's obviously one cell, managed by one server).

Then another aircraft starts chasing you and you decide to turn this into a space battle, knowing your faction has a much better advantage up there than down there (they moved a space battle station above the position they were attacking, but the ground forces of the enemy are still alive and kicking, for example). (the space will obviously be in another cell because it's so incredibly far, and contains it's own lot of objects and stuff).


Now in most games you'd climb and climb, and see a loading screen, then climb again.

That would make no sense at all from the perception of the aircraft in pursuit, and would break a lot of the immersion.


We need a solution without any loading screen or visible server switching to make this just awesome (imagine an aircraft chase from the ground into space, a space battle, and then the chase reverses as the hunter becomes the hunted, and flees down to the ground -- no interruptions, no loading screens, only amazing immersion).


For the server-side, I think the solution would be slightly overlapping cells, and silent connection to the next cell's server (servers actually because if you aim for the top corner of a cube you will be in a 4-cell overlap) at that point, tracking the aircraft and its projectiles in both grids.

The client would have a proper solution for dynamic loading of resources (a bit like a moving window concept) and would reconcile the inputs from multiple servers, discarding duplicate input (like when four cells track the same missile, only one collision will be recorded and the rest is safely discarded) and making a seamless transition between two cells, effectively creating an infinite immersion, no 1000m flight ceiling, no "go back to the combat zone", no crap.

If you want to take the 60 miles detour to attack from a better angle, suit yourself.
If you want to go from the planet to its moon in your little aircraft, suit yourself.

Code indentation

4-column tab

Consistency > your feelings about code indentation.





Spaces will never be consistent and require a lot of text-processing on commits and reads, etc. with no added benefit.

Tabs are semantically correct: one tab indents, where some number of spaces could mean anything.

When you set your own column width preference for tabs, the view is altered. This is logically correct.

When your editor transforms four-space-indents into 2-space-indents, the content is altered. This is incorrect.


8-cols are obviously a joke, as one can only imagine the result of 8-col tabs, 32-col TTY and 4 levels of indentation.

2-cols are rather unclear considering how people like adding "one space" everywhere for "clarity".

3-cols is not a power of 2, so it doesn't work.

4-cols is the best answer, it's both clear, not too wide and a power of 2.