Programación en Internet

En Accenture sued over website redesign so bad it Hertz: Car hire biz demands $32m+ for ‘defective’ cyber-revamp:

Car rental giant Hertz is suing over a website redesign from hell.

The US corporation hired monster management consultancy firm Accenture in August 2016 to completely revamp its online presence. The new site was due to go live in December 2017. But a failure to get on top of things led to a delay to January 2018, and then a second delay to April 2018 which was then also missed, we’re told.

As Hertz endured the delays, it found itself immersed in a nightmare: a product and design that apparently didn’t do half of what was specified and still wasn’t finished. “By that point, Hertz no longer had any confidence that Accenture was capable of completing the project, and Hertz terminated Accenture,” the car rental company complained in a lawsuit [PDF] lodged against Accenture in New York this month.

Hertz is suing for the $32m it paid Accenture in fees to get to that aborted stage, and it wants more millions to cover the cost of fixing the mess. “Accenture never delivered a functional website or mobile app,” Hertz claimed.

Accenture told El Reg on Tuesday this week it believes Hertz’s lawsuit is “without merit.”

Among the most mind-boggling allegations in Hertz’s filed complaint is that Accenture didn’t incorporate a responsive design, in which webpages automatically resize to accommodate the visitor’s screen size whether they are using a phone, tablet, desktop, or laptop.

That has been standard website practice for years and was even included in the contract that was signed, but the boffins at Accenture decided that only desktop and mobile versions were needed, according to Hertz. When the rental giant’s execs asked where the tablet version was, Accenture “demanded hundreds of thousands of dollars in additional fees to deliver the promised medium-sized layout.”

It actually gets worse.

The specs called for a common core of libraries to be “a fundamental principle of the design” so that the company could share information and structures across all its companies’ websites and apps. And Accenture, well, completely ignored that, according to Hertz.

“Accenture deliberately disregarded the extensibility requirement and wrote the code so that it was specific to the Hertz brand in North America and could not be used for the Hertz global brand or for the Dollar and Thrifty brands,” the lawsuit alleged.

En Microsoft renuncia a la caducidad de las contraseñas por ser un método inútil:

Microsoft renuncia a la caducidad de las contraseñas. A partir de ahora, no exigirá su cambio periódico tras comprobar que es una medida inútil e incluso peligrosa. Esta medida pretendía evitar que una cuenta fuera pirateada, pero según reconoce Aaron Margosis, consultor principal de la compañía, su efectividad es nula. “Si una contraseña no ha sido robada no hay necesidad de cambiarla. Y si hay evidencia de que ha sido robada, hay que actuar de inmediato, sin esperar a que caduque”, explica en el blog de seguridad de la compañía (Microsoft Security Guidance blog).

[…]

“La caducidad periódica de la contraseña es una fórmula antigua y obsoleta con muy poco valor y creemos que no es válida dentro de nuestra política de seguridad”, reconoce Margosis.

En Cómo funciona un navegador web por dentro, un curso divulgativo, se hace referencia al curso Inside look at modern web browser en el que se explica el funcionamiento del motor del navegador Google Chrome.

En Rendering on the Web se analizan las distintas formas que existen de generar páginas web en la actualidad:

As developers, we are often faced with decisions that will affect the entire architecture of our applications. One of the core decisions web developers must make is where to implement logic and rendering in their application. This can be a difficult, since there are a number of different ways to build a website.

Our understanding of this space is informed by our work in Chrome talking to large sites over the past few years. Broadly speaking, we would encourage developers to consider server rendering or static rendering over a full rehydration approach.

In order to better understand the architectures we’re choosing from when we make this decision, we need to have a solid understanding of each approach and consistent terminology to use when speaking about them. The differences between these approaches help illustrate the trade-offs of rendering on the web through the lens of performance.

Rendering

• SSR: Server-Side Rendering – rendering a client-side or universal app to HTML on the server.
• CSR: Client-Side Rendering – rendering an app in a browser, generally using the DOM.
• Rehydration: “booting up” JavaScript views on the client such that they reuse the server-rendered HTML’s DOM tree and data.
• Prerendering: running a client-side application at build time to capture its initial state as static HTML.

Performance

• TTFB: Time to First Byte – seen as the time between clicking a link and the first bit of content coming in.
• FP: First Paint – the first time any pixel gets becomes visible to the user.
• FCP: First Contentful Paint – the time when requested content (article body, etc) becomes visible.
• TTI: Time To Interactive – the time at which a page becomes interactive (events wired up, etc).

Desde hace un tiempo, esto se ha convertido en lo más normal:

Entras en una página web en el móvil y te sale el aviso de cookies que inunda toda la página web.

En el artículo To Grid or to Flex? se analizan las ventajas y desventajas de realizar un diseño con CSS Grid o CSS Flex:

What surprised me about reading the responses in the thread was the number of people stating that they would only use Grid for page-level layout, and flexbox for everything else. If you take this as a rule, then you’re severely limiting yourself when it comes to Grid’s power. The main piece of advice I would give is to take every design individually, analyse the options available and don’t make assumptions about which technology you need. Here are some of the questions you could ask yourself when it comes to choosing a layout method.

Often, if you’re having to use calc() a lot to get precise track sizes (factoring in gutters, for example) then it’s worth considering using Grid, as the fr unit will do the heavy lifting for you and save you any number of headaches. While that’s fine as a general principle, it’s not the whole picture. There are cases when you might need Grid, even though your layout doesn’t require calc(). One example might be a fixed-width, two-dimensional layout, where each track is 200px wide – you don’t need calc() to tell you how wide those tracks should be, but you might still want the behaviour of Grid. Likewise, there are cases for using flexbox where you do need calc(), so this can only be interpreted as a guideline.