A GitHub gist shows how to get around this problem:
$ redis-cli > config set stop-writes-on-bgsave-error no
I want to upload a CSV file from a page, and I also want to resist the urge to install a gem, which seems to be the default Rails developer behavior. No need to build a model; I just need a reference for the CSV for further processing somewhere. Here’s what I did:
First, I built a simple page with a form and a submit button. Ruby on Rails provides some helper methods to generate forms, namely form_with, form_for, and form_tag. I don’t need a model, so I used `form_tag` first. Unfortunately, I ran into this problem where the CSV file handle is not passed to the request. Instead, I used
form_with and I was able to parse the CSV.
I fixed this error by re-installing
Development environment booted successfully:
The book Understanding Software describes starting the right way.
How do you keep the design simple as the codebase grows? We want to avoid having a large codebase with no sound design. This could lead to the Big Rewrite, where nobody wins.
While incremental efforts such as refactoring could alleviate the pain of not having an established design, the team effort could have been prevented had there been some type of guidance at the beginning of a software project.
But what if you don’t know what the “right way” looks like at the beginning? A design would eventually emerge given enough time working on the system. This insight will not appear when you are pressed for time to build something or if your tenure in the project is measured in weeks.
To counter paralysis in choosing the “right design,” sometimes you just have to build something and stay long enough to experience the pain points of your implementation. Only by experiencing pain can one be instructed on how to improve their designs, especially after being paged at odd hours of the day.
What follows is my personal experience related to this LinkedIn post: it’s all good until the dominant values of a group change with staff turnover.
In early 2018, our project had some critical features built using Vue.js. In hindsight, the decision to use Vue.js wasn’t carefully deliberated: everybody (me included) was convinced we needed to use something that would support a complex UI. We needed to learn Vue.js quickly while building out these critical features. What initially was thought of helping to speed up development turned out to be a liability. Everybody (me included) seemed to know that using Vue.js for this project was the wrong choice, but did not stop primarily due to loss aversion and the lack of a suitable alternative.
At this point, the dominant group of developers has built a Vue.js frontend with all the supporting code needed to render these single-page applications. The team proceeded to build more features on Vue.js (I failed to constrain its scope), which continued until these developers started to leave. This was also the time we addressed bugs with the Vue.js code. The developers left to fix the problems were not the same developers who built the features, which led to time that needed to be spent on knowledge recovery (figuring out how things work) and applying fixes.
In mid-2018, difficult conversations started between our client and the team regarding quality and delivery pace. We decided we needed to stop using Vue.js and look for a suitable alternative that did not require a steep learning curve. At this point, the codebase was a mess to figure out, but it was workable due to the tests we’ve started to prepare for the critical features. A new dominant group has since emerged, which valued maintainability and remembered what came before. The new team had to work on a controlled mess: keeping the existing Vue.js implementation working while building an improved replacement in the background. This team also had to continue to deliver value to the business while rework is being done. The new team also was less than half of the size of the original team, which meant that the new structure had to be distilled into a set of patterns that new developers could grasp.
I found this gist yesterday while dealing with multiple node.js versions. I hope this saves you time.
This is my summary of The Future of Ops Jobs is Platform Engineering.
DevOps has succeeded in unifying developer and operations roles, but the problem remains: how can developers operate their code? Skills for operating an increasingly complex cloud infrastructure remain valuable, and the difficult infrastructure parts have been factored out as their own services (e.g. EKS versus bootstrapping your own Kubernetes cluster).
Platform engineering as vendor engineering
Vendor engineering refers to having the necessary experience with another vendor’s API. I encountered this term in The Future of Ops Jobs, which was one of the first attempts at describing this new role.
While most infrastructure tools are now companies of their own, teams are selecting these tools as part of their own platform’s toolchain. This involves making sense of multiple vendor APIs, and providing a path for the team to use daily. All this work is to focus the team’s attention on the product.
I noticed that realizing that this type of work is needed happens while building out a SaaS product. This type of work is necessary and, if not properly done, could distract the team from its mission.
Towards a self-service tier
All this tooling gives rise to the self-service tier, and the article describes what a self-service platform should have (e.g., deploy a service, instrument deployments, etc.). The goal would be for an engineer to quickly bring up a new service using the toolchain provided by the platform engineer. The toolchain serves as the “blessed stack” on what the team should use and is supported by the organization.
What happens to operations roles now?
This begs the question: are platform engineers just developers who happen to be assigned to build tools? Failure of platform engineering happens when the developer(s) assigned to do the work for this job have little experience in operating cloud software and, worse, have little empathy to make their teammates’ experience with the platform better.
The article compares a platform engineer’s job to a typical operations job. What caught my attention was the focus on running less software.
Job titles are lagging indicators
Similar to observability, I think we’ll see “platform engineer” job posts within a year or two.
We have a local saying (“weather-weather lang yan”). Storms eventually pass. I took this picture today while on my morning walk:
The waters were not always as calm this: last week, there was a typhoon. Today is a new day and another chance to do well if we can ride the turbulence.