This article serves to curate the articles that I’ve found interesting on my own learning journey but does not seem to be sufficient to be indicated as an individual post. We want to always spend some time over the weeks and months to learn new technology and tools that are out there. Strive to be curious about the world around you, and you will yourself in a different position as a software engineer or simply as an individual with a different perspective one year down the road. The step towards being an even more competent software engineer starts usually one side project at a time (I’ve got a new side project coming soon!) or an article at a time.
If you want to read good informative and interesting technical articles, here it is!(:
Technology in general
scalability of an architecture comes with planning. All success comes with sets of guiding principles and understanding these principles governs your thought processes through the decision making. The most basic approach is to be sets of stateless servers and a load balancer. As the load increases, you spawn up more instances of your server. But as you scale, your cost increases proportionally as well. So keep that in mind. Remember that your solution typically comprises of different microservices. As you increase the instances of your server to serve a larger quantity of request, remember to look downstream resources to ensure that shared resources are not overwhelmed. These shared resources will soon be bottlenecks and has to be exposed and resolved swiftly.
Interestingly, as you start to scale, you face new problems such as cascading failure. This failure is well explained in the article so check it out. And as you continue to face these problems, you’ve got to know how to deal with these challenges with the architecture patterns out there such as the Circuit Breaker which ive described in my previous post and bulk head. These patterns help to build resilience into your services, so the operation can still be up and running even if one of the components are dysfunctional. Always good to understand the principles behind resilient solutions even before you encounter them.
To deal with cache, it is crucial for the application side to deal with this. Get to understand if the cached data expires, it will then still query the database and load the results in the cache as well as return tot he caller.
A well designed caching scheme can be absolutely invaluable in scaling a system. If you can handle a large percentage of read requests from your cache, then you buy extra capacity at your databases as they are not involved in handling most requests.
If you want to scale, you have to monitor. You monitor the metrix that relates to the specifics of your application’s behaviour. Carefully design these metrics and add code into the microservices to inject them into the monitoring framework. Second, monitoring is a necessary function (and cost) in your system. It is turned on. Always. When you need to tune performance and scale your system, the data you capture guides your experiments and efforts. You want to be data-driven in your decisions to scale and improve the system.
AI are driven by data and thus without the access to data, AI models cannot work. What’s more, artificial research teams lack an awareness of the specific business processes and tasks that could be automated in the first place.So without this intuition of what kind of business processes they wish to automate, they could never focus on a specific model to train and thereupon automate the process.
Someone actually took the time to collate all the free tier Saas for developers! This is just so amazing! And it is interesting to see how there are actually just so much resources out there for you to try and play with your own experiments! Experiments also happens to be the next step i want to take to push myself deeper in my understanding of a tech! Definitely a site i will frequent to look out for free-bies.
I always wonder what are the uses for SSL_Ciphers. Going one step deeper into networking I believe you’ve heard of http and https which is http secure. This secure connection is done by encrypting the data packets before sending them. In order to establish this secure connection, the servers need to know what cipher to use based on the cipher suites installed and the preference of the server. This cipher once communicated will be used so that both servers know which cipher suite to decrypt the data packets.
From internet explorer, you can see the connection and cipher suite used
From chrome, you can click on the lock icon and see what connection is used
As a way to configure the cipher suites for Kubernetes ingress, this is the way to do so. You just need to add in this config into the ingress configuration:
If you wish to check the support cipher suites on your server:
/usr/bin/openssl ciphers -v
Cipher Suites are named combinations of:
- Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)
- Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)
- Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)
- Message Authentication Code Algorithms (SHA-256, POLY1305)
- Type of Encryption TLS v1.3, v1.2, v1.1, v1.0 or SSL v3, v2
After checking out the documentation, server-tokens configuration is a configuration to check if NGINX server header should be returned in responses and display NGINX version in error pages.
Reference for this snippet of code.
I find it interesting and, to be honest, odd that the author blatantly calls himself out for lying to us on the small details. Hahaha. I am not sure to be thankful, or amused to see an author doing that.
I love how the author shares with us on his mental model in understanding NIX. Mental models, as I’ve shared before about technology, are liken to be frameworks. This framework provides something liken to a storyline in which you can follow along. There are expectations you can set up to provide signals to guide the user through the thought process. Here’s an example: a message channel is like a bank branch office. You wish to perform a transaction and so you travel to a physical branch office. When you first arrive, you will be asked to collect a queue ticket that indicates your queue number. Next you take a seat while you see the current queue numbers being flashed on a monitor. Now you see 5-10 counters each occupied with an executive currently serving a customer. Similarly, the simplest concept of messaging queue used in [Competing consumer design pattern](https://blog.phuaxueyong.com/post/2020-04-10-first-four-design-pattterns) works with the concept of a single queue. And every request is added into a single queue to be picked up by any counter once they have completed their previous request. This idea of a banking branch office is a mental model to help us better understand a concept with a substitution of a story.
Youtube channel to go deep into Nix. Nix is a package management, including support for multiple versions of packages side-by-side with no issues. It makes all the dependencies of a software explicit in the form of a graph database. Graph are usually used to depict dependencies. In Nix, every node that is built will have to be built by a special node called Derivatives. Derivatives will explicitly list out all the dependencies needed to build a node in the Nix store.
Overall, I think it is really interesting to know tools that are created explicitly for dependency management in data builds. It does not interface with users, no networking, no file writing, and no output other than debug or tracing purposes. it is specifically built just for dependency management. This is definitely a type of tool to consider if you want to build big data networks. Still learning, and unlearning my understanding of deployment dependencies and pain points.
Nix lets you compose software at build time with maximum flexibility, and with builds being as reproducible as possible.
From nix documentation
More introduction to Nix from Phd Thesis. This paper is the go-to to understand the problem Nix is trying to solve, what is the context in which Nix package manager addresses, and how effectively did it address the problems.
Here is a whole playlist of Nix tutorials
The ability to write code together online is essential for digital education for coding. As companies shift their focus towards digital classes, it is essential to build the right tools for the job. If you wan to teach over the net, digital classrooms that gives you the space to give out assessments and also to mark attendence.
Really simple syndication. Previously it was Google reader, but now Feedly. Consume your resources and information in one centralised place as well, creates a lot of convenience.
The return of RSS will be accompanied by the return of blogging. perhaps this is the next step you can take your blog towards: The one thing i will bring back to the internet will be blogs
This article was talking about how native desktop apps are far superior to Web applications. Really? There are a few factors of comparison, which is pretty neat.
- Display Performance. Native apps or mobile apps are running at 60fps while applications on the web are running on 3fps. The plus point was that native apps runs at 60fps out of the box without much effort.
- efficient use of resources. Native apps are able to use the GPU more efficiently. Since there are a lot more information about which controls are being used, you can recycle your resources more efficiently
- Development environment. There are a vast arrays of language you can use to write native apps. But I do see the web engine improving over the years as well. Will look more thoroughly into this aspect when the opportunity comes hehe.
Over the past decade, “neofeudalism” has emerged to name tendencies associated with extreme inequality, generalized precarity, monopoly power, and changes at the level of the state.
The structure of complex networks invites inclusion: the more items in the network, the larger the rewards for those at the top. It also induces competition — for attention, resources, money, jobs — anything that is given a network form.
Very hard to read and need to understand the different structures of society, what are its merits and credits. But thought it was an interesting article to push some knowledge boundaries.
I know how this guy points out a valid point that working from home isn’t so much of working from home. The idea of working from home introduces a concept of flexibility. You are able to work from anywhere that allows you to prioritize productivity. And that is most important. What you want isnt to just perceive the work from home solely as that confinement. Understand how as the world starts to open up and the bigger companies are embracing this new mode of work, remember that prioritizing your productivity is most important. If wherever you are sitting is killing your productivity, move along.
I always believe such a perspective can be related to our approach towards a technical solution that you need to work on. If this particular approach A does not work, move along! Do not get stuck at it and subconsciously start a pity party for yourself. Get yourself another perspective by either pulling another engineer into your discussion or read up just how other engineers or companies are solving problems such as yours.
Senior engineers usually know that a code base might be messy but software is most useful when it accurately models the world. some code may have to be ugly because it needs to capture the essential complexity of the domain.
“The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed.”
Just to reference the article’s point. These are the few points that a strong senior engineer can offer to the business:
- Communicate with non-technical team members
- Help solve issues across a variety of technologies
- Understand the business side of a product
- Lend their years of hands-on experience to their team members
Technology and Sales
Once again, another article about the need to sell your work as a developer. Often times, much work by developers to either create a new feature or to fix a bug go untold. Perhaps there was not a perceived need to share what we have done, since getting the work done and into deployment is already an achievement in itself. But that is not enough. The value or the benefit is not reaped or recognised unless it is utilized by the intended end user. Unless you are the only end user you have in mind, you got to share it out. I guess one of the hinderances to share your work is a fear of criticism. It definitely takes courage to put your work out in public’s view, making your work susceptible to people’s seemingly ruthless comments. But because we fear the unknown, we often times over-emphasise scenarios of cruel criticisms when often times, you get more feedback that can actually help you sharpen your idea.
Be courageous. You are doing a good work to even attempt to solve a problem, least to even share your work with us. Keep it up! (: