feat: add ghirkin format

public/blogs/branded-types.mdx

@@ -189,5 +189,5 @@ const baz2 = requestBaz(foo.id, bar.id);
   showLineNumbers={true}
 />
 <C>
-Oh btw,`ts-roids` is a library I created this week, the goal is to bulletproof TypeScript with types and decorators, it includes more than 120+ utilities at the time of writing, you can check it out <L href="https://github.com/ashgw/ts-roids">here</L>.
+Oh btw, `ts-roids` is a library I created this week, the goal is to bulletproof TypeScript with types and decorators, it includes more than 120+ utilities at the time of writing, you can check it out <L href="https://github.com/ashgw/ts-roids">here</L>
 </C>

public/blogs/management-skill-issues.mdx

@@ -39,7 +39,7 @@ To ensure the success of the project, it's imperative for me (and my team, as we
 <H2>I Get Paid Regardless</H2>
 
 <C>
-If I'm putting in hours of my life, knowing that my efforts won't be financially rewarded any differently, regardless of whether I excel or just meet the minimum requirements, then why bother going above and beyond? Why care about the success or failure of the project, I get paid anyway? I'll leave that headache to you. My role is simply to fulfill my contractual obligations which is to spend "x" number of hours staring at a screen, probably aimlessly scrolling through social media for fleeting dopamine hits, attend some meetings from time to time, collect my paycheck, and navigate this dystopian existence within the confines of my office until I randomly get "laid off", and repeat the cycle again with another company.
+If I'm putting in <L href="https://zachholman.com/posts/how-github-works-hours/">hours</L> of my life, knowing that my efforts won't be financially rewarded any differently, regardless of whether I excel or just meet the minimum requirements, then why bother going above and beyond? Why care about the success or failure of the project, I get paid anyway? I'll leave that headache to you. My role is simply to fulfill my contractual obligations which is to spend "x" number of hours staring at a screen, probably aimlessly scrolling through social media for fleeting dopamine hits, attend some meetings from time to time, collect my paycheck, and navigate this dystopian existence within the confines of my office until I randomly get "laid off", and repeat the cycle again with another company.
 
 
 </C>
@@ -53,12 +53,7 @@ If I'm putting in hours of my life, knowing that my efforts won't be financially
 <C>
 So the more tickets I close, the greater my earnings. If I can swiftly churn through tickets, I'll boost my income, this motivates me to excel, think harder, and learn more. The faster I solve problems, the sooner I reap rewards and enjoy free time. This directly translates to faster product shipping with higher <L href="/blog/software-quality">quality,</L> increasing the likelihood of overall product success. This benefits everyone involved,  so everyone can <L href="https://youtu.be/k6eTY-ayPaE?si=xTJ0AMNhbegfyx7k&t=13">get a bag</L>.
 </C>
-<H2>The Mob Had No Time For Coporate BS </H2>
 
-
-<C>
-The mob's near takeover of major sectors in America in the 20th century stands as a testament to their efficient and results-oriented work ethic, where compensation is not based on time spent but on results. **Leaders** within these organizations must be adept at delegating tasks **efficiently**, and ensuring that operations run smoothly. Failure to produce results can have **serious consequences** for everyone involved which creates a competitive culture of **self accountability** and **high performance.** Individuals are always **self responsible** for their own outcome. When given a task, if they succeed, they get rewarded (paid), if they don't, they won't get rewarded (no pay), If they mess up badly or enough times they either go prison or get killed (get fired)
-</C>
 <H2>Reward And Punishment </H2>
 <C>
 Individual accountability is self-imposed, programmers are self-disciplined and self-motivated. They know what they work for, how to achieve better results, and exactly what needs to be done in order to help the project move forward. You don't have to <L href="/blog/micro-management">micromanage</L> people, your job is to give them <L href="https://www.atlassian.com/blog/productivity/how-to-write-smart-goals#:~:text=The%20SMART%20in%20SMART%20goals,within%20a%20certain%20time%20frame">S.M.A.R.T</L> tasks, and let meritocracy guide the progress. Team member must own their tasks and outcomes. This is the environment where top performers thrive while those who fall short are encouraged to either improve or leave. 
@@ -86,5 +81,5 @@ If layoffs are necessary, be honest about it. We all have to cut corners to save
 
 <H2 id="conclusion">Conclusion</H2>
 <C>
-Unless your team get paid for deliverables like <L href="/blog/software-quality">software quality</L>, closed <L href="/services/glossary#tickets">tasks,</L> documents, products shipped etc..), it will spend 90% of its time in meetings, coffee breaks and conference calls, playing pong or acting like monkeys for entertainment, basically wasting 90% of the client's money is just wasted away.
+Unless your team get paid for deliverables like <L href="/blog/software-quality">software quality</L>, closed <L href="/services/glossary#tickets">tasks,</L> documents, products shipped etc..), it will spend 90% of its time in meetings, coffee breaks and conference calls, playing pong or acting like monkeys for entertainment, basically wasting 90% of the allocated budget at this point.
 </C>

public/blogs/user-stories.mdx

@@ -0,0 +1,199 @@
+---
+title: User Stories
+seoTitle:  How to Write Effective User Stories
+summary: How to write effective User Stories
+isReleased: true
+isSequel: false
+lastModDate: 2023-06-14T09:15:00-0401
+firstModDate: 2023-06-14T09:15:00-0401
+minutesToRead: 6
+tags:
+  - 'user-stories'
+  - 'srs'
+---
+<C>
+User stories are a vital component of agile software development, that allows software teams to capture user needs and translate them into actionable requirements. Here's a comprehensive guide on crafting effective user stories.
+</C>
+<H2>Understanding User Stories</H2>
+<C>
+A user story is a concise description of a software feature from an end user's perspective, narrated using non-technical language. It typically follows the format: "As a **persona**, I want to **software goal**, so that **result**".
+</C>
+<C>
+The term "end user" can refer to external customers or internal stakeholders benefiting from the feature.
+</C>
+<H2>Writing Effective User Stories</H2>
+<C>
+Understand the target audience's demographics and psychographics to define the user persona accurately. Design the feature to address their needs and help them achieve their goals, focusing on user intent rather than technical details. Also
+</C>
+
+<H3>Adhere to INVEST Criteria</H3>
+<C>
+An effective user story should adhere to the [INVEST]() criteria to ensure clarity, feasibility, and value delivery:
+</C>
+
+<C>
+ **Independent:** User stories should be self-contained and independent, to enable teams to develop and deliver them without reliance on other stories.
+</C>
+
+
+
+<C>
+**Valuable:** Each user story should deliver tangible value to the end user or stakeholder, by enhancing functionality, user experience, or productivity.
+</C>
+
+
+
+
+<C>
+**Estimable:** User stories should be sufficiently detailed to allow for [estimation]() of effort and duration required for implementation
+</C>
+
+
+<C>
+**Small:** User stories should be broken down into small, manageable chunks of work that can be completed within a single [sprint.]()
+</C>
+
+
+
+<C>
+**Negotiable:** User stories should be open to negotiation and refinement throughout the development process to accommodate evolving requirements.
+</C>
+
+<C>
+**Testable:** More on this [later.]()
+</C>
+
+<C>
+**Prioritized:** More on this [later.]()
+</C>
+
+<H2>Fixing Common Mistakes in User Stories</H2>
+
+<C>
+**Use Consistent Language:** Establish a [glossary]() early in the project to define terms consistently and ensure clarity across all stakeholders
+</C>
+
+
+
+
+
+<C>
+**Focus on User Goals:** Understand the underlying user intent behind each story. Consult real users or representatives to refine requirements accurately.
+</C>
+
+
+
+
+<C>
+**Remove Technical Details If not needed:** Separate user goals from implementation specifics to maintain relevance and flexibility. Should the user get notified by [Kafka]() or a web hook? Does it really matter? The user just wants to get notified, using either technology won't matter, in the end. But will it matter if the user receives the notification through email or other means? Yes.
+</C>
+
+
+
+
+<C>
+**Clarifying Roles:** Yes it's called User Story but, not everyone is a user. Tailor user stories to specific user roles (e.g., manager, admin, architect, [group leader?](https://www.urbandictionary.com/define.php?term=group%20leader) ) to ensure features meet diverse user needs. 
+</C>
+
+<H2>Good and Bad User Story Examples</H2>
+
+
+<C>
+You might find these ones in the wild
+</C>
+<H3>Bad Examples</H3>
+<C>
+ **#1:** As a user, I want a button on the homepage.
+  - **\>  Problem:** This user story lacks context, purpose, and specific user intent.
+</C>
+<C>
+ **#2:**  As a developer, I want to refactor the codebase.
+  - **\>  Problem:** Focuses solely on the developer's task, missing value or outcome.
+  </C>
+<C>
+ **#3:** As a manager, I want reports.
+  - **\>  Problem:** Doesn't specify the purpose or value of the reports for the user. These reports can literally be about anything.
+  </C>
+<C>
+ **#1:** As a first time website visitor, I want the landing page to be fast.
+  - **\>  Problem:** Vague and lacks clarity on the specific performance improvement needed. How can "fast" be tested? Is there a concrete metric? Is it fast on a Mac? Or an old android? How many milliseconds should it take to be considered "fast"?
+  </C>
+<H3>Good Examples</H3>
+<C>
+ **#1:** As a registered user, I want to reset my password via email verification if forgot it, so that I can regain access to my account.
+  - **\>  Persona:** Registered User.
+  - **\>  Needs:** Password reset functionality.
+  - **\>  Purpose:** Account security and user autonomy.
+</C>
+<C>
+ **#1:** As a customer, I want to receive email notifications for order updates, so that I can track the status of my purchases conveniently.
+  - **\>  Persona:** Customer.
+  - **\>  Needs:** Order status update.
+  - **\>  Purpose:**  Enhanced customer experience and order management.
+</C>
+<C>
+ **#1:** As a project manager, I want a web dashboard displaying real-time project milestones and tickets completion, so that I can monitor project progress to make informed decisions.
+  - **\>  Persona:** Project Manager
+  - **\>  Needs:** Real-time project metrics
+  - **\>  Purpose:**  Improved project visibility and decision-making
+</C>
+<H2>Testability</H2>
+<C>
+Rewrite user stories using Behavior-Driven Development format, such as [Gherkin]() syntax, so you can directly map these stories to executable tests, and ensure that the software meets the specified requirements and behaviors.
+</C>
+<H2>Gherkin Syntax</H2>
+
+
+
+<C>
+This is how to write user stories in Gherkin syntax 
+</C>
+<H3>Example 1: Password Reset Feature</H3>
+<C>
+*"As a registered user, I want to reset my password via email verification, so that I can regain access to my account securely."* Can be written as
+</C>
+<Code
+  code={`Feature: Password Reset
+
+  Scenario: User resets password via email verification
+    Given I am a registered user
+    And I have forgotten my password
+    When I request a password reset via email
+    Then I should receive an email with a password reset link
+    And I click on the password reset link
+    And I set a new password
+    Then I should be able to log in with my new password
+`}
+  language="gherkin"
+  showLineNumbers={false}
+/>
+
+
+<C>
+You see how better it gets? Here's another one 
+</C>
+<H3>Example 2: Order Status Notifications</H3>
+<C>
+*"As a customer, I want to receive email notifications for order updates, so that I can track the status of my purchases conveniently."* Can be written as
+</C>
+<Code
+  code={`Feature: Order Status Notifications
+
+  Scenario: Customer receives email notification for order updates
+    Given I am a customer with pending orders
+    When an order status changes (shipped, delivered)
+    Then I should receive an email notification with the updated status
+    And I can click on the email to view detailed order information
+`}
+  language="gherkin"
+  showLineNumbers={false}
+/>
+
+
+<H2>Ranking</H2>
+<C>
+And yeah, did I mention that, when a user story is set, it needs a priority level. The method you use might [differ](https://www.altexsoft.com/blog/most-popular-prioritization-techniques-and-methods-moscow-rice-kano-model-walking-skeleton-and-others/), in [my projects]() I use the [MoSCoW]() method.
+</C>
+
+
+

public/services/deadlines.mdx

@@ -40,10 +40,10 @@ Additional time is always allocated for addressing unexpected challenges, but, w
 - \- Drop low-priority features.
 </C>
 <C>
-Sacrificing quality is a short-term fix, it will inevitably lead to issues later on. Most software teams that opt for this approach end up with unmaintainable code, resulting in numerous bugs, performance issues, or even requiring a complete project rewrite. This is approach is never to be considered. 
+Sacrificing quality is a short-term fix, it will inevitably lead to issues later on. It's basically shooting yourself in the foot. Most software teams that opt for this approach end up with unmaintainable code, resulting in numerous bugs, performance issues, or even requiring a complete project rewrite. This is approach is never to be considered. 
 </C>
 <C>
-Outsourcing work is a viable solution, but it comes with additional costs. Therefore, it's only considered when it provides a positive ROI
+Outsourcing work is a viable solution, but it comes with additional costs. Therefore, it's only considered when it provides a positive <L href="https://en.wikibooks.org/wiki/Poker/Expected_value">EV</L>
 </C>
 <C>
 The latter option maximizes utility and minimizes losses the most, which in this case, is the optimal play. Before one drops features, they must already be: 

src/app/components/reusables/code/code-block.tsx

@@ -17,6 +17,7 @@ import yaml from 'react-syntax-highlighter/dist/cjs/languages/prism/yaml';
 import http from 'react-syntax-highlighter/dist/cjs/languages/prism/http';
 import sql from 'react-syntax-highlighter/dist/cjs/languages/prism/sql';
 import sass from 'react-syntax-highlighter/dist/cjs/languages/prism/sass';
+import gherkin from 'react-syntax-highlighter/dist/cjs/languages/prism/gherkin';
 
 import oneDark from 'react-syntax-highlighter/dist/cjs/styles/prism/one-dark';
 import CopyButton from './copy-code';
@@ -35,6 +36,7 @@ SyntaxHighlighter.registerLanguage('yaml', yaml);
 SyntaxHighlighter.registerLanguage('http', http);
 SyntaxHighlighter.registerLanguage('sql', sql);
 SyntaxHighlighter.registerLanguage('sass', sass);
+SyntaxHighlighter.registerLanguage('gherkin', gherkin);
 
 export type CodeBlockProps = {
   language: string;