diff options
| author | Paul Buetow <paul@buetow.org> | 2023-08-19 11:28:07 +0300 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2023-08-19 11:28:07 +0300 |
| commit | 5162ceb2cd04cc644015c79a75591b4d3818cd38 (patch) | |
| tree | cb555690d1b45e4c1cf04fc357e76b4d1777f4ae | |
| parent | 33fa99b86a004e723e31b23aaca1865a90e26e70 (diff) | |
Update content for html
| -rw-r--r-- | gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html | 4 | ||||
| -rw-r--r-- | gemfeed/2023-08-18-site-reliability-engineering-part-1.html | 2 | ||||
| -rw-r--r-- | gemfeed/DRAFT-site-reliability-engineering.html | 2 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 1947 | ||||
| -rw-r--r-- | gemfeed/index.html | 2 | ||||
| -rw-r--r-- | index.html | 4 | ||||
| -rw-r--r-- | notes/career-guide-and-soft-skills.html | 4 | ||||
| -rw-r--r-- | notes/index.html | 2 | ||||
| -rw-r--r-- | uptime-stats.html | 2 |
9 files changed, 690 insertions, 1279 deletions
diff --git a/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html b/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html index 501c5b15..e6468978 100644 --- a/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html +++ b/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html @@ -2,13 +2,13 @@ <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> -<title>'Software Developmers Career Guide %%TITLE%% Soft Skills' book notes</title> +<title>'Software Developmers Career Guide and Soft Skills' book notes</title> <link rel="shortcut icon" type="image/gif" href="/favicon.ico" /> <link rel="stylesheet" href="../style.css" /> <link rel="stylesheet" href="style-override.css" /> </head> <body> -<h1 style='display: inline'>"Software Developmers Career Guide & Soft Skills" book notes</h1><br /> +<h1 style='display: inline'>"Software Developmers Career Guide and Soft Skills" book notes</h1><br /> <br /> <span class='quote'>Published at 2023-07-17T04:56:20+03:00</span><br /> <br /> diff --git a/gemfeed/2023-08-18-site-reliability-engineering-part-1.html b/gemfeed/2023-08-18-site-reliability-engineering-part-1.html index 03c3f334..05ef4ba2 100644 --- a/gemfeed/2023-08-18-site-reliability-engineering-part-1.html +++ b/gemfeed/2023-08-18-site-reliability-engineering-part-1.html @@ -41,7 +41,7 @@ DC on fire: <br /> <h2 style='display: inline'>SRE and Organizational Culture: Navigating the Nexus</h2><br /> <br /> -<span>At the heart of SRE lies the proactive mindset of 'prevention over cure'. Traditional IT models focused predominantly on reactive solutions, but SRE mandates a shift towards foresight. By adopting Service Level Indicators (SLIs) and Service Level Objectives (SLOs), teams are equipped with clear metrics and goals that guide them toward ensuring reliability and user satisfaction. However, these aren't mere numbers. They reflect an organisational culture prioritising user experience and constant system alignment with user needs. </span><br /> +<span>At the heart of SRE lies the proactive mindset of "prevention over cure". Traditional IT models focused predominantly on reactive solutions, but SRE mandates a shift towards foresight. By adopting Service Level Indicators (SLIs) and Service Level Objectives (SLOs), teams are equipped with clear metrics and goals that guide them toward ensuring reliability and user satisfaction. However, these aren't mere numbers. They reflect an organisational culture prioritising user experience and constant system alignment with user needs. </span><br /> <br /> <span>Another defining SRE concept is the "error budget". This ingenious framework accepts that no system is flawless. Failures are inevitable. However, instead of being punitive, the culture here is to accept, learn, and iterate. By providing teams with a "budget" for errors, organisations foster an environment where innovation is encouraged, and failures are viewed as learning opportunities.</span><br /> <br /> diff --git a/gemfeed/DRAFT-site-reliability-engineering.html b/gemfeed/DRAFT-site-reliability-engineering.html index c8fba6ad..f7c9949c 100644 --- a/gemfeed/DRAFT-site-reliability-engineering.html +++ b/gemfeed/DRAFT-site-reliability-engineering.html @@ -10,7 +10,7 @@ <body> <h2 style='display: inline'>On-Call Culture and the Human Aspect: Prioritising Well-being in the Realm of Reliability</h2><br /> <br /> -<span>Site Reliability Engineering is synonymous with ensuring system reliability, but the human factor is an often-underestimated component of this discipline. It is evident that fostering a healthy on-call culture is as critical as any technical solution. In the world of constant alerts, pages, and incident management, the well-being of the engineers becomes paramount.</span><br /> +<span>Site Reliability Engineering is synonymous with ensuring system reliability, but the human factor is an often-underestimated component of this discipline. Fostering a healthy on-call culture is as critical as any technical solution. In the world of constant alerts, pages, and incident management, the well-being of the engineers becomes paramount.</span><br /> <br /> <span>Firstly, a healthy on-call rotation is about more than just managing and responding to incidents. It's about the entire ecosystem that supports this practice. Establishing happy and healthy on-call rotations is akin to possessing a superpower. This involves reducing pain points, offering mentorship, rapid iteration, and ensuring that engineers have the right tools and processes. It acknowledges that while systems are crucial, the engineers who maintain them are invaluable.</span><br /> <br /> diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index ffb78621..db0678e4 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,18 +1,605 @@ <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> - <updated>2023-07-12T07:37:47+03:00</updated> + <updated>2023-08-19T11:27:51+03:00</updated> <title>foo.zone feed</title> <subtitle>To be in the .zone!</subtitle> <link href="https://foo.zone/gemfeed/atom.xml" rel="self" /> <link href="https://foo.zone/" /> <id>https://foo.zone/</id> <entry> + <title>Site Reliability Engineering - Part 2: Operational Balance in SRE</title> + <link href="https://foo.zone/gemfeed/2023-08-19-site-reliability-engineering-part-2.html" /> + <id>https://foo.zone/gemfeed/2023-08-19-site-reliability-engineering-part-2.html</id> + <updated>2023-08-19T00:18:18+03:00</updated> + <author> + <name>Paul Buetow aka snonux</name> + <email>paul@dev.buetow.org</email> + </author> + <summary>This is the second part of my Site Reliability Engineering (SRE) series. I am currently employed as a Principal Site Reliability Engineer and will attempt to share what SRE is about in this blog series.</summary> + <content type="xhtml"> + <div xmlns="http://www.w3.org/1999/xhtml"> + <h1 style='display: inline'>Site Reliability Engineering - Part 2: Operational Balance in SRE</h1><br /> +<br /> +<span class='quote'>Published at 2023-08-19T00:18:18+03:00</span><br /> +<br /> +<span>This is the second part of my Site Reliability Engineering (SRE) series. I am currently employed as a Principal Site Reliability Engineer and will attempt to share what SRE is about in this blog series.</span><br /> +<br /> +<a class='textlink' href='./2023-08-18-site-reliability-engineering-part-1.html'>2023-08-18 Site Reliability Engineering - Part 1: SRE and Organizational Culture</a><br /> +<a class='textlink' href='./2023-08-19-site-reliability-engineering-part-2.html'>2023-08-19 Site Reliability Engineering - Part 2: Operational Balance in SRE (You are currently reading this)</a><br /> +<br /> +<pre> +⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣾⣷⣄⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ +⠀⠀⠀⠀⣾⠿⠿⠿⠶⠾⠿⠿⣿⣿⣿⣿⣿⣿⠿⠿⠶⠶⠿⠿⠿⣷⠀⠀⠀⠀ +⠀⠀⠀⣸⢿⣆⠀⠀⠀⠀⠀⠀⠀⠙⢿⡿⠉⠀⠀⠀⠀⠀⠀⠀⣸⣿⡆⠀⠀⠀ +⠀⠀⢠⡟⠀⢻⣆⠀⠀⠀⠀⠀⠀⠀⣾⣧⠀⠀⠀⠀⠀⠀⠀⣰⡟⠀⢻⡄⠀⠀ +⠀⢀⣾⠃⠀⠀⢿⡄⠀⠀⠀⠀⠀⢠⣿⣿⡀⠀⠀⠀⠀⠀⢠⡿⠀⠀⠘⣷⡀⠀ +⠀⣼⣏⣀⣀⣀⣈⣿⡀⠀⠀⠀⠀⣸⣿⣿⡇⠀⠀⠀⠀⢀⣿⣃⣀⣀⣀⣸⣧⠀ +⠀⢻⣿⣿⣿⣿⣿⣿⠃⠀⠀⠀⠀⣿⣿⣿⣿⠀⠀⠀⠀⠈⢿⣿⣿⣿⣿⣿⡿⠀ +⠀⠀⠉⠛⠛⠛⠋⠁⠀⠀⠀⠀⢸⣿⣿⣿⣿⡆⠀⠀⠀⠀⠈⠙⠛⠛⠛⠉⠀⠀ +⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⣿⣿⣿⣿⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ +⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣾⣿⣿⣷⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ +⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣸⣿⣿⣿⣿⣿⣿⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ +⠀⠀⠀⠀⠀⠀⠴⠶⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠿⠶⠦⠀⠀ +</pre> +<br /> +<h2 style='display: inline'>Operational Balance in SRE: Finding the Equilibrium in Reliability and Velocity</h2><br /> +<br /> +<span>Site Reliability Engineering has established itself as more than just a set of best practices or methodologies. Instead, it stands as a beacon of operational excellence, which guides engineering teams through the turbulent waters of modern software development and system management.</span><br /> +<br /> +<span>In the universe of software production, two fundamental forces are often at odds: The drive for rapid feature release (velocity) and the need for system reliability. Traditionally, the faster teams moved, the more risk was introduced into systems. SRE offers a approach to mitigate these conflicting drives through concepts like error budgets and SLIs/SLOs. These mechanisms provide a tangible metric, allowing teams to quantify how much they can push changes while ensuring they don't compromise system health. Thus, the error budget becomes a balancing act, where teams weigh the trade-offs between innovation and reliability.</span><br /> +<br /> +<span>A quintessential component of this balance is the dichotomy between operations and coding. According to SRE principles, an engineer should ideally spend an equal amount of time on operations work and coding - 50% on each. This isn't just a random metric; it's a reflection of the value SRE places on both maintaining operational excellence and progressing forward with innovations. This balance ensures that while SREs are solving today's problems, they are also preparing for tomorrow's challenges. </span><br /> +<br /> +<span>However, not all operational tasks are equal. SRE differentiates between "ops work" and "toil". While ops work is integral to system maintenance and can provide value, toil represents repetitive, mundane tasks which offer little value in the long run. Recognising and minimising toil is crucial. A culture that allows engineers to drown in toil stifles innovation and growth. Hence, an organisation's approach to toil indicates its operational health and commitment to balance.</span><br /> +<br /> +<span>A cornerstone of achieving operational balance lies in the tools and processes SREs use. Effective monitoring, observability tools, and ensuring that tools can handle high cardinality data are foundational. These aren't just technical requisites but reflective of an organisational culture prioritising proactive problem-solving. By having systems that effectively flag potential issues before they escalate, SREs can maintain the delicate balance between system stability and forward momentum.</span><br /> +<br /> +<span>Moreover, operational balance isn't just a technological or process challenge; it's a human one. The health of on-call engineers is as crucial as the health of the services they manage. On-call postmortems, continuous feedback loops, and recognising gaps (be it tooling, operational expertise, or resources) ensure that the human elements of operations are noticed. </span><br /> +<br /> +<span>In conclusion, operational balance in SRE is not a static thing but an ongoing journey. It requires organisations to constantly evaluate their practices, tools, and, most importantly, their culture. By achieving this balance, organisations can ensure that they have time for innovation while maintaining the robustness and reliability of their systems, resulting in sustainable long-term success.</span><br /> +<br /> +<span>That all sounds very romantic. The truth is, it is brutal to archive the perfect balance. No system will ever be perfect. But at least we should aim for it!</span><br /> +<br /> +<span>The third part of this blog series will be published soon :-)</span><br /> +<br /> +<span>E-Mail your comments to paul at buetow.org :-)</span><br /> +<br /> +<a class='textlink' href='../'>Back to the main site</a><br /> + </div> + </content> + </entry> + <entry> + <title>Site Reliability Engineering - Part 1: SRE and Organizational Culture</title> + <link href="https://foo.zone/gemfeed/2023-08-18-site-reliability-engineering-part-1.html" /> + <id>https://foo.zone/gemfeed/2023-08-18-site-reliability-engineering-part-1.html</id> + <updated>2023-08-18T22:43:47+03:00</updated> + <author> + <name>Paul Buetow aka snonux</name> + <email>paul@dev.buetow.org</email> + </author> + <summary>The universe of Site Reliability Engineering (SRE) is like an intricate tapestry woven with diverse technology, culture, and personal grit threads. Site Reliability Engineering is one of the most demanding jobs. With all the facets, it is impossible to get bored. There is always a new challenge to master, and there is always a new technology to tinker with. It's not just technical; it's also about communication, collaboration and teamwork. I am currently employed as a Principal Site Reliability Engineer and will attempt to share what SRE is about in this blog series.</summary> + <content type="xhtml"> + <div xmlns="http://www.w3.org/1999/xhtml"> + <h1 style='display: inline'>Site Reliability Engineering - Part 1: SRE and Organizational Culture</h1><br /> +<br /> +<span class='quote'>Published at 2023-08-18T22:43:47+03:00</span><br /> +<br /> +<span>The universe of Site Reliability Engineering (SRE) is like an intricate tapestry woven with diverse technology, culture, and personal grit threads. Site Reliability Engineering is one of the most demanding jobs. With all the facets, it is impossible to get bored. There is always a new challenge to master, and there is always a new technology to tinker with. It's not just technical; it's also about communication, collaboration and teamwork. I am currently employed as a Principal Site Reliability Engineer and will attempt to share what SRE is about in this blog series.</span><br /> +<br /> +<a class='textlink' href='./2023-08-18-site-reliability-engineering-part-1.html'>2023-08-18 Site Reliability Engineering - Part 1: SRE and Organizational Culture (You are currently reading this)</a><br /> +<a class='textlink' href='./2023-08-19-site-reliability-engineering-part-2.html'>2023-08-19 Site Reliability Engineering - Part 2: Operational Balance in SRE</a><br /> +<br /> +<pre> +▓▓▓▓░░ + +DC on fire: + + ▓▓ ▓▓ ▓▓ + ░░ ░░ ▓▓▓▓ ██ ░░ ▓▓▓▓ ▓▓ + ▓▓░░░░ ░░ ▓▓▓▓ ▓▓░░ ▓▓▓▓ + ░░░░ ▓▓▓▓▓▓ ▓▓ ▓▓ ▓▓ ▓▓▓▓▓▓ ▓▓ + ▓▓░░ ▓▓▒▒▒▒▓▓▓▓ ▓▓ ▓▓▓▓ ▓▓▓▓▓▓ ▓▓▒▒▒▒▓▓▓▓ ▓▓▓▓ + ██▓▓ ▓▓▒▒░░▒▒▓▓ ▓▓██ ▓▓▓▓▓▓ ▓▓▒▒▓▓ ▓▓▒▒░░▒▒▓▓ ██▓▓▓▓ + ▓▓▓▓██ ▓▓▒▒░░░░▒▒▓▓ ▓▓▓▓ ▓▓▒▒▒▒▓▓ ▓▓▒▒░░▒▒▓▓██▓▓ ▓▓▒▒░░░░▒▒▓▓ ▓▓▒▒▒▒▓▓ + ▓▓▒▒▒▒▓▓▓▓▒▒░░▒▒▓▓▓▓▓▓▒▒▒▒▓▓ ▓▓▓▓░░▒▒▓▓ ▓▓▒▒░░▒▒▓▓▒▒▒▒▓▓ ▓▓▒▒░░▒▒▓▓▓▓▓▓▓▓░░▒▒▓▓ + ▒▒░░▒▒▓▓▓▓▒▒░░▒▒▓▓▓▓▒▒░░▒▒▓▓ ▓▓▒▒░░▒▒▓▓ ▓▓░░░░▒▒▒▒░░░░▒▒██████▒▒░░▒▒██▓▓▓▓▒▒░░▒▒▓▓██ + ░░░░▒▒▓▓▒▒░░▒▒▓▓▓▓▓▓▒▒░░▒▒▓▓██▒▒░░░░▒▒▓▓ ▓▓▒▒░░▒▒▓▓▒▒▒▒░░▒▒▓▓▓▓▒▒░░▒▒▓▓▓▓▓▓▒▒░░░░▒▒▓▓▓▓ + ░░░░▒▒▓▓▒▒░░░░▓▓██▒▒░░░░▒▒▓▓██▒▒░░░░▒▒██▓▓▓▓▒▒░░▒▒▓▓▓▓▒▒░░░░▒▒▓▓▒▒░░░░██▓▓▓▓▒▒░░░░▒▒████ + ▒▒░░▒▒▓▓▓▓░░░░▒▒▓▓▒▒▒▒░░░░▒▒▓▓▓▓▒▒░░░░▒▒▓▓▓▓▒▒░░░░▒▒▓▓▒▒░░▒▒▓▓▓▓▓▓░░░░▒▒▓▓▓▓▓▓▒▒░░░░▒▒▓▓ + ▒▒░░▒▒▓▓▒▒▒▒░░▒▒██▒▒▒▒░░▒▒▒▒██▒▒▒▒░░░░░░▒▒▓▓▒▒░░░░▒▒▒▒░░░░▒▒████▒▒▒▒░░▒▒██▓▓▒▒▒▒░░░░░░▒▒ + ░░░░░░▒▒░░░░░░░░▒▒▒▒▒▒░░░░▒▒▒▒▒▒░░░░░░░░▒▒▒▒░░░░░░▒▒▒▒░░░░░░▒▒▒▒░░░░░░░░▒▒▒▒▒▒░░░░░░░░▒▒ + ░░░░░░░░░░▒▒░░░░░░░░░░░░░░░░░░░░░░░░▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒░░░░░░░░░░░░░░░░░░ +</pre> +<br /> +<h2 style='display: inline'>SRE and Organizational Culture: Navigating the Nexus</h2><br /> +<br /> +<span>At the heart of SRE lies the proactive mindset of "prevention over cure". Traditional IT models focused predominantly on reactive solutions, but SRE mandates a shift towards foresight. By adopting Service Level Indicators (SLIs) and Service Level Objectives (SLOs), teams are equipped with clear metrics and goals that guide them toward ensuring reliability and user satisfaction. However, these aren't mere numbers. They reflect an organisational culture prioritising user experience and constant system alignment with user needs. </span><br /> +<br /> +<span>Another defining SRE concept is the "error budget". This ingenious framework accepts that no system is flawless. Failures are inevitable. However, instead of being punitive, the culture here is to accept, learn, and iterate. By providing teams with a "budget" for errors, organisations foster an environment where innovation is encouraged, and failures are viewed as learning opportunities.</span><br /> +<br /> +<span>But SRE isn't just about technology and metrics; it's deeply human. It challenges the "hero culture" that plagues many IT teams. While individual heroics might occasionally save the day, a sustainable model requires collective expertise. An SRE culture recognises that heroes achieve their best within teams, negating the need for a hero-centric environment. This philosophy promotes a balanced on-call experience, emphasising the importance of trust, ownership, effective communication, and collaboration as cornerstones of team success. I personally have fallen into the hero trap, and I know it is unsustainable to be the only go-to person for every problem.</span><br /> +<br /> +<span>Additionally, the SRE model requires good documentation. However, it's essential to ensure that this documentation undergoes the same quality checks as code, reinforcing effective onboarding, training and communication.</span><br /> +<br /> +<span>Organisations might face a significant challenge when adopting SRE. It is convincing various teams and leadership of its merits. Some might feel SRE principles counter their goals. They might prioritise feature rollouts over reliability or view SRE practices as cumbersome. Hence, fostering an SRE culture often demands patient explanations and showcasing tangible benefits, such as increased release velocity and improved user experience.</span><br /> +<br /> +<span>Monitoring and observability form another SRE pillar, emphasising the need for high-quality tools to query and analyse data. This ties back to the cultural emphasis on continuous learning and adaptability. SREs, by nature, need to be curious, ready to delve into anomalies, and keen on adopting new tools and practices. </span><br /> +<br /> +<span>Ultimately, the success of SRE within any organisation depends on the broader acceptance of its principles. It demands a move away from siloed operations, where SRE acts as a bandage on flawed systems, to a model where reliability is everyone's responsibility. It calls for cultural transformation from the on-call engineers to the boardroom.</span><br /> +<br /> +<span>In essence, the integration of SRE principles transcends technical practices. It paves the way for a shift in organisational culture that values proactive prevention, continuous learning, collaboration, and transparent communication. The successful melding of SRE and corporate culture promises not just reliable systems but also a robust, resilient, and progressive work environment.</span><br /> +<br /> +<span>Organisations with the implementation of SLIs, SLOs and error budgets are already advanced in their SRE journey. It takes a lot of communication, convincing, and patience until that point is reached.</span><br /> +<br /> +<span>Continue with the second part of this series:</span><br /> +<br /> +<a class='textlink' href='./2023-08-19-site-reliability-engineering-part-2.html'>2023-08-19 Site Reliability Engineering - Part 2: Operational Balance in SRE</a><br /> +<br /> +<span>E-Mail your comments to paul at buetow.org :-)</span><br /> +<br /> +<a class='textlink' href='../'>Back to the main site</a><br /> + </div> + </content> + </entry> + <entry> + <title>Gemtexter 2.1.0 - Let's Gemtext again³</title> + <link href="https://foo.zone/gemfeed/2023-07-21-gemtexter-2.1.0-lets-gemtext-again-3.html" /> + <id>https://foo.zone/gemfeed/2023-07-21-gemtexter-2.1.0-lets-gemtext-again-3.html</id> + <updated>2023-07-21T10:19:31+03:00</updated> + <author> + <name>Paul Buetow aka snonux</name> + <email>paul@dev.buetow.org</email> + </author> + <summary>I proudly announce that I've released Gemtexter version `2.1.0`. What is Gemtexter? It's my minimalist static site generator for Gemini Gemtext, HTML and Markdown, written in GNU Bash.</summary> + <content type="xhtml"> + <div xmlns="http://www.w3.org/1999/xhtml"> + <h1 style='display: inline'>Gemtexter 2.1.0 - Let's Gemtext again³</h1><br /> +<br /> +<span class='quote'>Published at 2023-07-21T10:19:31+03:00</span><br /> +<br /> +<pre> +-=[ typewriters ]=- 1/98 + .-------. + .-------. _|~~ ~~ |_ + _|~~ ~~ |_ .-------. =(_|_______|_) + =(_|_______|_)= _|~~ ~~ |_ |:::::::::| + |:::::::::| =(_|_______|_) |:::::::[]| + |:::::::[]| |:::::::::| |o=======.| + |o=======.| |:::::::[]| `"""""""""` + jgs `"""""""""` |o=======.| + mod. by Paul Buetow `"""""""""` +</pre> +<br /> +<span>I proudly announce that I've released Gemtexter version <span class='inlinecode'>2.1.0</span>. What is Gemtexter? It's my minimalist static site generator for Gemini Gemtext, HTML and Markdown, written in GNU Bash.</span><br /> +<br /> +<a class='textlink' href='https://codeberg.org/snonux/gemtexter'>https://codeberg.org/snonux/gemtexter</a><br /> +<br /> +<h2 style='display: inline'>Why Bash?</h2><br /> +<br /> +<span>This project is too complex for a Bash script. Writing it in Bash was to try out how maintainable a "larger" Bash script could be. It's still pretty maintainable and helps me try new Bash tricks here and then!</span><br /> +<br /> +<span>Let's list what's new!</span><br /> +<br /> +<h2 style='display: inline'>Switch to GPL3 license</h2><br /> +<br /> +<span>Many (almost all) of the tools and commands (GNU Bash, GMU Sed, GNU Date, GNU Grep, GNU Source Highlight) used by <span class='inlinecode'>Gemtexter</span> are licensed under the GPL anyway. So why not use the same? This was an easy switch, as I was the only code contributor so far!</span><br /> +<br /> +<h2 style='display: inline'>Source code highlighting support</h2><br /> +<br /> +<span>The HTML output now supports source code highlighting, which is pretty neat if your site is about programming. The requirement is to have the <span class='inlinecode'>source-highlight</span> command, which is GNU Source Highlight, to be installed. Once done, you can annotate a bare block with the language to be highlighted. E.g.:</span><br /> +<br /> +<pre> + ```bash + if [ -n "$foo" ]; then + echo "$foo" + fi + ``` +</pre> +<br /> +<span>The result will look like this (you can see the code highlighting only in the Web version, not in the Geminispace version of this site):</span><br /> +<br /> +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">if</font></b> <font color="#990000">[</font> -n <font color="#FF0000">"$foo"</font> <font color="#990000">];</font> <b><font color="#0000FF">then</font></b> + echo <font color="#FF0000">"$foo"</font> +<b><font color="#0000FF">fi</font></b> +</pre> +<br /> +<span>Please run <span class='inlinecode'>source-highlight --lang-list</span> for a list of all supported languages.</span><br /> +<br /> +<h2 style='display: inline'>HTML exact variant</h2><br /> +<br /> +<span>Gemtexter is there to convert your Gemini Capsule into other formats, such as HTML and Markdown. An HTML exact variant can now be enabled in the <span class='inlinecode'>gemtexter.conf</span> by adding the line <span class='inlinecode'>declare -rx HTML_VARIANT=exact</span>. The HTML/CSS output changed to reflect a more exact Gemtext appearance and to respect the same spacing as you would see in the Geminispace. </span><br /> +<br /> +<h2 style='display: inline'>Use of Hack webfont by default</h2><br /> +<br /> +<span>The Hack web font is a typeface designed explicitly for source code. It's a derivative of the Bitstream Vera and DejaVu Mono lineage, but it features many improvements and refinements that make it better suited to reading and writing code.</span><br /> +<br /> +<span>The font has distinctive glyphs for every character, which helps to reduce confusion between similar-looking characters. For example, the characters "0" (zero), "O" (capital o), and "o" (lowercase o), or "1" (one), "l" (lowercase L), and "I" (capital i) all have distinct looks in Hack, making it easier to read and understand code at a glance.</span><br /> +<br /> +<span>Hack is open-source and freely available for use and modification under the MIT License.</span><br /> +<br /> +<h2 style='display: inline'>HTML Mastodon verification support</h2><br /> +<br /> +<span>The following link explains how URL verification works in Mastodon:</span><br /> +<br /> +<a class='textlink' href='https://joinmastodon.org/verification'>https://joinmastodon.org/verification</a><br /> +<br /> +<span>So we have to hyperlink to the Mastodon profile to be verified and also to include a <span class='inlinecode'>rel='me'</span> into the tag. In order to do that add this to the <span class='inlinecode'>gemtexter.conf</span> (replace the URI to your Mastodon profile accordingly):</span><br /> +<br /> +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF">declare</font></b> -xr <font color="#009900">MASTODON_URI</font><font color="#990000">=</font><font color="#FF0000">'https://fosstodon.org/@snonux'</font> +</pre> +<br /> +<span>and add the following into your <span class='inlinecode'>index.gmi</span>:</span><br /> +<br /> +<pre> +=> https://fosstodon.org/@snonux Me at Mastodon +</pre> +<br /> +<span>The resulting line in the HTML output will be something as follows:</span><br /> +<br /> +<!-- Generator: GNU source-highlight 3.1.9 +by Lorenzo Bettini +http://www.lorenzobettini.it +http://www.gnu.org/software/src-highlite --> +<pre><b><font color="#0000FF"><a</font></b> <font color="#009900">href</font><font color="#990000">=</font><font color="#FF0000">'https://fosstodon.org/@snonux'</font> <font color="#009900">rel</font><font color="#990000">=</font><font color="#FF0000">'me'</font><b><font color="#0000FF">></font></b>Me at Mastodon<b><font color="#0000FF"></a></font></b> +</pre> +<br /> +<h2 style='display: inline'>More</h2><br /> +<br /> +<span>Additionally, there were a couple of bug fixes, refactorings and overall improvements in the documentation made. </span><br /> +<br /> +<span>Other related posts are:</span><br /> +<br /> +<a class='textlink' href='./2021-04-24-welcome-to-the-geminispace.html'>2021-04-24 Welcome to the Geminispace</a><br /> +<a class='textlink' href='./2021-06-05-gemtexter-one-bash-script-to-rule-it-all.html'>2021-06-05 Gemtexter - One Bash script to rule it all</a><br /> +<a class='textlink' href='./2022-08-27-gemtexter-1.1.0-lets-gemtext-again.html'>2022-08-27 Gemtexter 1.1.0 - Let's Gemtext again</a><br /> +<a class='textlink' href='./2023-03-25-gemtexter-2.0.0-lets-gemtext-again-2.html'>2023-03-25 Gemtexter 2.0.0 - Let's Gemtext again²</a><br /> +<a class='textlink' href='./2023-07-21-gemtexter-2.1.0-lets-gemtext-again-3.html'>2023-07-21 Gemtexter 2.1.0 - Let's Gemtext again³ (You are currently reading this)</a><br /> +<br /> +<span>E-Mail your comments to paul at buetow.org :-)</span><br /> +<br /> +<a class='textlink' href='../'>Back to the main site</a><br /> + </div> + </content> + </entry> + <entry> + <title>'Software Developmers Career Guide and Soft Skills' book notes</title> + <link href="https://foo.zone/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html" /> + <id>https://foo.zone/gemfeed/2023-07-17-career-guide-and-soft-skills-book-notes.html</id> + <updated>2023-07-17T04:56:20+03:00</updated> + <author> + <name>Paul Buetow aka snonux</name> + <email>paul@dev.buetow.org</email> + </author> + <summary>These notes are of two books by 'John Sommez' I found helpful. I also added some of my own keypoints to it. These notes are mainly for my own use, but you might find them helpful, too.</summary> + <content type="xhtml"> + <div xmlns="http://www.w3.org/1999/xhtml"> + <h1 style='display: inline'>"Software Developmers Career Guide and Soft Skills" book notes</h1><br /> +<br /> +<span class='quote'>Published at 2023-07-17T04:56:20+03:00</span><br /> +<br /> +<span>These notes are of two books by "John Sommez" I found helpful. I also added some of my own keypoints to it. These notes are mainly for my own use, but you might find them helpful, too.</span><br /> +<br /> +<pre> + ,.......... .........., + ,..,' '.' ',.., + ,' ,' : ', ', + ,' ,' : ', ', + ,' ,' : ', ', + ,' ,'............., : ,.............', ', +,' '............ '.' ............' ', + '''''''''''''''''';''';'''''''''''''''''' + ''' +</pre> +<br /> +<h1 style='display: inline'>Improve</h1><br /> +<br /> +<h2 style='display: inline'>Always learn new things</h2><br /> +<br /> +<span>When you learn something new, e.g. a programming language, first gather an overview, learn from multiple sources, play around and learn by doing and not consuming and form your own questions. Don't read too much upfront. A large amount of time is spent in learning technical skills which were never use. You want to have a practical set of skills you are actually using. You need to know 20 percent to get out 80 percent of the results.</span><br /> +<br /> +<ul> +<li>Learn a technology with a goal, e.g. implement a tool. Practice practise practice.</li> +<li>"I know X can do Y, I don't know exactly how, but I can look it up."</li> +<li>Read what experts are writing, for example follow blogs. Stay up to date and spent half an hour per day trading blogs and books.</li> +<li>Pick an open source application, read the code and try to understand it to get a feel of the syntax of the programming language.</li> +<li>Understand, that the standard library makes you a much better programmer.</li> +<li>Self learning is the top skill a programmer can have and is also useful in other aspects in your life.</li> +<li>Keep learning skills every day. Code every day. Don't be overconfident for job security. Read blogs, read books.</li> +<li>If you want to learn, then do it by exploring. Also teach what you learned (for example write a blog post or hold a presentation).</li> +</ul><br /> +<span>Fake it until you make it. But be honest about your abilities or lack of. There is however only time between now and until you make it. Refer to your abilities to learn.</span><br /> +<br /> +<span>Boot camps: The advantage of a boot camp is to pragmatically learn things fast. We almost always overestimate what we can do in a day. Especially during boot camps. Connect to others during the boot camps</span><br /> +<br /> +<h2 style='display: inline'>Set goals</h2><br /> +<br /> +<span>Your own goals are important but the manager also looks at how the team performs and how someone can help the team perform better. Check whether you are on track with your goals every 2 weeks in order to avoid surprises for the annual review. Make concrete goals for next review. Track and document your progress. Invest in your education. Make your goals known. If you want something, then ask for it. Nobody but you knows what you want.</span><br /> +<br /> +<h2 style='display: inline'>Ratings</h2><br /> +<br /> +<span>That's a trap: If you have to rate yourself, that's a trap. That never works in an unbiased way. Rate yourself always the best way but rate your weakest part as high as possible minus one point. Rate yourself as good as you can otherwise. Nobody is putting for fun a gun on his own head. </span><br /> +<br /> +<ul> +<li>Don't do peer rating, it can fire back on you. What if the colleague becomes your new boss?</li> +<li>Cooperate rankings are unfortunately HR guidelines and politics and only mirror a little your actual performance.</li> +</ul><br /> +<h2 style='display: inline'>Promotions</h2><br /> +<br /> +<span>The most valuable employees are the ones who make themselves obsolete and automate all away. Keep a safety net of 3 to 6 months of finances. Safe at least 10 percent of your earnings. Also, if you make money it does not mean that you have to spent more money. Is a new car better than a used car which both can bring you from A to B? Liability vs assets.</span><br /> +<br /> +<ul> +<li>Raise or promotion, what's better? Promotion is better as money will follow anyway then.</li> +<li>Take projects no-one wants and make them shine. A promotion will follow.</li> +<li>A promotion is not going to come to you because you deserve it. You have to hunt and ask for it.</li> +<li>Track all kudos (e.g. ask for emails from your colleagues).</li> +<li>Big corporations HRs don't expect a figjit. That's why it's so important to keep track of your accomplishments and kudos'.</li> +<li>If you want a raise be specific how much and know to back your demands. Don't make a thread and no ultimatums.</li> +<li>Best way for a promotion is to switch jobs. You can even switch back with a better salary.</li> +</ul><br /> +<h2 style='display: inline'>Finish things</h2><br /> +<br /> +<span>Hard work is necessary for accomplish results. However, work smarter not harder. Furthermore, working smart is not a substitute for working hard. Work both, hard and smart.</span><br /> +<br /> +<ul> +<li>Learn to finish things without motivation. Things will pay off when you stick to stuff and eventually motivation can also come back.</li> +<li>You will fail if you don't plan realistically. Set also a schedule and follow to it as of life depends on it.</li> +<li>Advances come only of you give more than asked. Consistency, commitment and knowing what you need to do is more key than hard work.</li> +<li>Any action is better than no action. If you get stuck you have gained nothing.</li> +<li>You need to know the unknowns. Identify as many unknown not known things as possible. </li> +</ul><br /> +<span>Hard vs fun: Both engage the brain (video games vs work). Some work is hard and other is easy. Hard work is boring. The harsh truth is you have to put in hard and boring work in order to accomplish and be successful. Work won't be always boring though, as joy will follow with mastery.</span><br /> +<br /> +<span>Defeat is finally give up. Failure is the road to success, embrace it. Failure does not define you but how you respond to it. Events don't make your unhappy, but how you react to events do.</span><br /> +<br /> +<h2 style='display: inline'>Expand the empire</h2><br /> +<br /> +<span>The larger your empire is, the larger your circle of influence is. The larger the circle of influence is, the more opportunities you have.</span><br /> +<br /> +<ul> +<li>Do the dirty work if you want to expand the empire. That's there the opportunities are.</li> +<li>SCRUM often fails due to the lack to commitment. The backlog just becomes a wish to get completed.</li> +<li>Apply work on your quality standards. Don't cross the line of compromise. Always improve your skills. Never be happy being good enough.</li> +</ul><br /> +<span>Become visible, keep track that you accomplishments. E.g. write a weekly summary. Do presentations, be seen. Learn new things and share your learnings. Be the problem solver and not the blamer.</span><br /> +<br /> +<h2 style='display: inline'>Be pragmatic and also manage your time</h2><br /> +<br /> +<span>Make use of time boxing via the Pomodoro technique: Set a target of rounds and track the rounds. That give you exact focused work time. That's really the trick. For example set a goal of 6 daily pomodores.</span><br /> +<br /> +<ul> +<li>Every time you do something question why does it make sense be pragmatic and don't follow because it is best practice.</li> +<li>You can also apply the time boxing technique (Cal Newport) for focused deep work.</li> +</ul><br /> +<span>You should feel good of the work done even if you don't finished the task. You will feel good about pomodoro wise even you don't finish the task on hand yet. Helps you to enjoy time off more. Working longer may not sell anything.</span><br /> +<br /> +<h3 style='display: inline'>The quota system</h3><br /> +<br /> +<span>Defined quota of things done. E.g. N runs per week or M Blog posts per month or O pomodoros per week. This helps with consistency. Truly commit to these quotas. Failure is not an option. Start with small commitments. Don't commit to something you can't fulfill otherwise you set yourself up for failure.</span><br /> +<br /> +<ul> +<li>Why does the quota System work? Slow and consistent pace is the key. It also overcomes willpower weaknesses as goals are preset.</li> +<li>Internal motivation is more important over external motivation. Check out Daniels book drive.</li> +<li>Multitasking: Batching is effective. E.g. emails twice daily at pre-set times..</li> +</ul><br /> +<h3 style='display: inline'>Don't waste time</h3><br /> +<br /> +<span>The biggest time waster is TV watching. The TV is programming you. It's insane that Americans wa |