Category Archives: technology

Coding

2024 Reading list (updated as we go)

Edge CDN techniques : Shielding from fastly i.e. use a designated edge cache instead of origin https://docs.fastly.com/en/guides/shielding on a edge cache miss.

Apple car not interesting anymore : https://www.bloomberg.com/news/articles/2024-02-27/apple-cancels-work-on-electric-car-shifts-team-to-generative-ai

golang error handling the Uber way : https://github.com/uber-go/guide/blob/master/style.md#errors

nginx forking : Maxim Dounin annouces https://freenginx.org/en/ on the nginx forum https://forum.nginx.org/read.php?2,299130

Quad 9 free dns 9.9.9.9 : https://www.quad9.net/

UI testing the netflix way : https://netflixtechblog.com/introducing-safetest-a-novel-approach-to-front-end-testing-37f9f88c152d

Check it out : the new super-ide https://zed.dev/

Lex/Yacc today : https://langium.org/

Inside Stripe Engineering Culture, a series a posts : https://newsletter.pragmaticengineer.com/p/stripe

I find truly interesting the point around promoting a write culture (Execs/Directors in tech blog, SWEs on tech blogs/internal technical documents) : https://newsletter.pragmaticengineer.com/i/140970283/writing-culture
I’m a long-time believer that writing clarifies thinking more than talking and writing persists information, makes it searchable, talking does not. “Verba volant, scripta manent” as the Latins use to say. But this idea shifted into “just enough” documentation (which means it is not necessary) in SW engineering latest methodologies so it is interesting that a multi billion company like stripe is going totally against the tide.

sunovermonte

The charm of complication

(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :

  1. Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
  2. Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
  3. Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
  4. Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
  5. Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
  6. Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
  7. Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
  8. Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
  9. Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
  10. Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.

Web design patterns

Heidelberg

You’ve probably seen these acronyms around : SSG, SSR, MPA, SPA, PWA. Web design is getting complex and this tries to explain (with the help of other good content) what these acronyms mean :

  • PWA : Progressive Web App, web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features. Not sure if this is a web design pattern
  • MPA : Multi Page Application, every operation requests data from server, receives a new page (html+css+js) and renders the data in the browser.
  • SPA : Single Page Application, performs inside a browser and does not require page reloading during its use. Initial html+cs+js is obtained from the server and then all login is done in js browser side.More info here and here
  • CSR : Client Side Rendering, all rendering happens in the browser. Use when UI is complex, lots of dynamic data, you need auth and SEO contents are not that many.
  • SSR : Server Side Rendering, as the acronyms imply, renders content in the server and sends ready .html+js files to the browser. Browser still executes js to reload pages. Use when UI has little interactivity, when you need best SEO and faster loading.
  • SSG : Static Site Generating, all pages are already generated and rendered server side.

There are several popular frameworks that can be used for static site generation (SSG) and server-side rendering (SSR).

For SSG, some popular options include Gatsby, Next.js, and Jekyll. These frameworks use a variety of technologies, such as React, Vue, and Ruby, to generate static HTML pages from dynamic content.

For SSR, some popular options include Express, Flask, and Hapi. These frameworks use Node.js and other technologies to generate the HTML for a page on the server and send it to the client.

Overall, there are many different frameworks available for both SSG and SSR, and the best choice will depend on the specific needs and goals of the project. It is important to carefully evaluate the features and capabilities of each framework to determine which one is the best fit for the project.

What is Software Development ?

According to Steve McConnell “Code Complete” there are plenty of metaphors out there:

This last view seems to be shared by many ( https://signalvnoise.com/posts/591-brainstorm-the-software-garden , Jeff Atwood likes it too https://blog.codinghorror.com/tending-your-software-garden/ and I feel close to him on really many things) and I tend to see it more close to what software development is today : a continuously changing (growing) artifact, not totally manageable, that requires constant maintenance (here the building metaphor fails a bit), designed and redesigned over time like a garden, subject to seasons (“lots of new requirements” season, “robustness and reliability” season).