Forem: Rajasegar Chandran

React inside Ember - The Second Chapter

Rajasegar Chandran — Fri, 12 Jul 2024 07:21:49 +0000

A year ago, I wrote an article here about invoking React components from Ember where I outlined an approach of rendering React components inside Ember templates or components using a complex and sophisticated mechanism.

Invoking React components from your Ember apps

Rajasegar Chandran ・ Jan 31 '23

#react #ember #javascript #webpack

After trying it out in our organization, we have found that there are a lot of downsides and productivity concerns in implementing that approach.

Limitations of the old approach

Converting existing repo to a workspace or monorepo
Setup complex build tooling with webpack
Extra wrapper components for passing in props
No hot module reloading support
Cannot yield child components from Ember

Advantages of the new approach

With the new addon approach by using the ember-react-fc addon, the process looks much simpler and we can overcome many downsides that were outlined in the previous post. Let's discuss the advantages of the new approach one by one here in detail.

No workspace or monorepo setup required

With this new approach, you don't have to convert your repo to a monorepo or workspace like we did in the old one. You can simply put your React components inside the app/components, may be with a new namespace like app/components/react and use it like this:

<React::HelloWorld @name="Raja"/>

No complex setup required

Previously, we have been compiling React component code using babel plugins using webpack config in Ember cli using the auto-import plugin. The problem with this approach is that, we need to install a lot of dependencies like babel plugins, react libraries and have to configure the webpack in such a way that it picks up only the files with JSX extensions referred from a different package inside a workspace.

ember-react-fc

ember-react-fc is an Ember addon to incrementally migrate your Ember code starting from components to React. This addon supports the latest React version 18 and functional components. The addon takes care of a lot of things like adding the respective babel plugins to compile JSX, react and react-dom dependencies to your Ember projects, support for .jsx extensions inside your Ember apps and so on.

You can install it in your Ember projects like below and start writing your components in React and they will work out of the box.

ember install ember-react-fc

This addon also comes with a component blueprint so that you can also generate component boiler plates for your React component.

You can generate React components like this:

ember generate react-component hello-world

No wrapper components required

In the old approach, we need to create Ember wrapper components for each React component we were creating. This creates an unnecessary overhead to have Ember duplicates for React components. But with this approach we are just invoking React components inside Ember templates and components in Ember way.

<div>
<h3>I am a Ember Component</h3>
<HelloReact @message={{this.message}}
            @onClick={{this.toggle}} />
</div>

Automatic reloading

In the old approach, we have kept our React components inside a (yarn or pnpm) workspace, so the changes inside this workspace won't affect the Ember build. Since Ember will only look for changes inside the app/ folder, it was proving very difficult to propagate the changes in React components to Ember build pipeline.

This problem we overcame in the new approach since we are keeping the React components inside the Ember app itself, any change you make to your React components will automatically get picked up by ember-cli.

React can have Ember children

There was no way previously to pass Ember components as children to React components in the old approach. But now you can put Ember components inside React as children. There is some room for misunderstanding here. What I meant by using Ember components as children is that when you are using the markup in your Ember templates, you can give Ember components as children to React components but not inside JSX in React.

This will work:

<React::HelloWorld @name="Raja"> 
<MyEmberComponent @arg1="abc" @arg2=true />
</React::HelloWorld>

This won't work:

import React from 'react';
import WithEmberSupport from 'ember-react-fc';

export default WithEmberSupport(function FunctionalComponent({message, onClick}) {

  return (
    <div id="wrapper" aria-label="hello">
      <button onClick={onClick}>Toggle</button>
      <div>you said: {message}</div>
      <MyEmberComponent @arg1="abc" @arg2=true />
    </div>
  );
});

This is a sample Ember app with the addon ember-react-fc installed and React components created and rendered inside Ember templates.

Inspiration

The inspiration for this addon came from previous works by Alex LaFroscia like ember-react-components. But that project got abandoned some 3 years ago and it is not made for the latest React versions. I cleaned up the addon by removing the logic for class components, made it work with latest React v18, fixed some issues and so on.

Hope you enjoyed the post and let me know your feedback and thoughts in the comment section. Please give the addon a try and let me know for any issues.

Vim-style repeatable key bindings for navigating windows in Emacs

Rajasegar Chandran — Thu, 06 Jun 2024 05:51:00 +0000

Vim-style repeatable key bindings for navigating windows in Emacs
1. Navigating windows in Emacs
2. windmove
3. repeat-mode
4. Key bindings
5. References

Vim-style repeatable key bindings for navigating windows in Emacs

In this post we are going to see how to create easily accessible
key bindings for jumping around windows inside Emacs in a directional manner. We are also going to make this key bindings repeatable to make the navigation awesome, along with Vim-style navigation using h,j,k,l keys

Navigating windows in Emacs

Before I came up with this workflow, I have been using C-x o to switch to windows in Emacs. The biggest problem with this for me is to complete the window cycle to switch to the desired window which is the immediate left window from my current one. I stumbled across the windmove commands and start using them. Finally I came up with an intuitive key binding in Vim style to use the home row keys like h,j,k,l

windmove

Windmove is a library built into GnuEmacs starting with version 21.
It lets you move point from window to window using Shift and the arrow keys. This is easier to type than ‘C-x o’ and, for some users, may be more intuitive. To activate all these keybindings, add the following to your InitFile:


    (when (fboundp 'windmove-default-keybindings)
      (windmove-default-keybindings))

You also might need to enable windmove-wrap-around setting if you wish to enable wrapping around window navigation.

    (setq windmove-wrap-around t)

This setting will control whether movement off the edge of the frame wraps around. If this variable is set to t, moving left from the leftmost window in a frame will find the rightmost one, and similarly for the other directions.

repeat-mode

repeat-mode is a global minor mode.
When Repeat mode is enabled, certain commands bound to multi-key
sequences can be repeated by typing a single key, after typing the
full key sequence once. The commands which can be repeated like that are those whose symbol has the property ‘repeat-map’ which specifies a keymap of single keys for repeating.

You can check out the current repeat maps enabled in your Emacs with M-x describe-repeat-maps

Please ensure you have enabled repeat-mode in your Emacs config by adding:

    (repeat-mode 1)

Key bindings

Now let's take a look at mapping the windmove commands to simple
keybindings starting with the C-c w prefix:

    (global-set-key (kbd "C-c w h") 'windmove-left)
    (global-set-key (kbd "C-c w j") 'windmove-down)
    (global-set-key (kbd "C-c w k") 'windmove-up)
    (global-set-key (kbd "C-c w l") 'windmove-right)

In order to make the key bindings repeatable we have to define a new repeat-map using the defvar-keymap function with the repeat property set to true.

    (defvar-keymap windmove-repeat-map
    :repeat t
    "h" #'windmove-left
    "j" #'windmove-down
    "k" #'windmove-up
    "l" #'windmove-right)

Hope you enjoyed the post and the new key bindings are helpful for you to navigate your windows in Emacs. Please let me know your thoughts and feedback in the comments section

References

Exploring Syntax Trees in Emacs with Tree-sitter

Rajasegar Chandran — Tue, 14 May 2024 06:24:19 +0000

In this post, we are going to take a look at an awesome feature in Emacs for exploring Syntax Trees using Treesitter. Before diving into the topic let's set some context.

I am a big fan of ASTs due to the application of them to solve complex problems like doing large scale migrations and code transformations in a big codebase. These code modifications are candidly known as "codemods". Since I am a codemod enthusiast, ASTs are are my bread and butter. I am also maintaining an awesome list of codemods here

Abstract Syntax Trees

An abstract syntax tree (AST) serves as a data structure employed to depict the arrangement of a program or code snippet. It offers a tree-shaped representation of the essential syntactic structure of text, often code composed in a formal language. Each node within the tree signifies a construct present in the text, sometimes simply referred to as a syntax tree.

The term "abstract" in this context implies that it captures the fundamental structural or content-related aspects rather than every minutiae found in the actual syntax. For example, grouping parentheses are inferred within the tree structure, eliminating the need for them to be represented as distinct nodes. Similarly, a syntactic entity like an if-condition-then statement might be represented by a solitary node with three branches.

This sets apart abstract syntax trees from concrete syntax trees, conventionally known as parse trees. Parse trees are typically constructed by a parser during the translation and compilation of source code. Subsequent processing, such as contextual analysis, supplements the AST with additional information.

Beyond their initial purpose, abstract syntax trees find application in program analysis and transformation systems.

Emacs

Emacs is a highly extensible, customizable, and powerful text editor primarily used in the field of software development and computer programming. Developed by Richard Stallman and initially released in the 1970s, Emacs has since evolved into a versatile platform offering a wide array of features beyond basic text editing.

One of Emacs's defining characteristics is its capability for extensive customization and extension using its built-in Lisp programming language. Users can tailor Emacs to suit their specific needs by writing or installing custom scripts and packages, enabling functionalities such as syntax highlighting, code completion, version control integration, and much more.

Emacs also offers a range of advanced editing features, including multiple buffers and windows, macro recording and playback, search and replace with regular expressions, and support for various programming languages and markup formats.

Moreover, Emacs provides a range of built-in modes and tools for various tasks, such as programming, text formatting, email, web browsing, and even games. It has a steep learning curve due to its extensive feature set and the need to become proficient with its keybindings and commands, but many users find that the investment pays off in terms of productivity and efficiency once mastered.

Emacs is available on various platforms, including Unix-like operating systems (such as Linux and macOS), Windows, and others, making it a popular choice among developers and power users across different computing environments.

Treesitter

Tree-sitter is a parsing system and incremental parser generator framework primarily used for programming language processing. Developed by the GitHub team, it provides robust and efficient parsing capabilities for various programming languages.

At its core, Tree-sitter employs a bottom-up parsing approach to construct Abstract Syntax Trees (ASTs) for source code. What sets it apart is its incremental parsing feature, which enables it to update the AST incrementally as the source code changes, offering significant performance advantages over traditional parsing techniques.

Tree-sitter is designed to be highly efficient, making it suitable for use cases where real-time or near-real-time parsing is required, such as in code editors and IDEs. Its incremental parsing capability allows code editors to provide features like syntax highlighting, code folding, code navigation, and intelligent code completion with minimal delay, even for large codebases.

Furthermore, Tree-sitter's parsing rules are defined using a declarative domain-specific language, making it easy to specify grammars for new programming languages or customize existing grammars. This flexibility allows Tree-sitter to support a wide range of programming languages and dialects.

Overall, Tree-sitter is a powerful tool for parsing and analyzing source code efficiently, making it a popular choice among developers building code editors, IDEs, static analysis tools, and other language processing applications.

treesit-explore-mode

treesit-explore-mode is a feature in Emacs that provides a graphical interface for exploring and interacting with syntax trees generated by the Tree-sitter parsing system. This mode is particularly useful for developers who work with programming languages supported by Tree-sitter and want to visually inspect the structure of their code.

When activated, treesit-explore-mode displays the syntax tree of the current buffer in a separate buffer, usually split vertically or horizontally alongside the original code buffer. The syntax tree is represented as a hierarchical structure, where each node corresponds to a syntactic construct in the code, such as functions, loops, conditionals, and expressions.

The graphical interface of treesit-explore-mode allows users to navigate through the syntax tree, expand and collapse nodes, and inspect the properties of individual nodes. This can be helpful for understanding the structure of complex code, identifying syntax errors, or debugging issues related to syntax highlighting or code analysis.

Additionally, treesit-explore-mode may provide features for interacting with the syntax tree, such as highlighting nodes corresponding to the current cursor position in the code buffer, or providing context-sensitive information about selected nodes.

Overall, treesit-explore-mode enhances the development experience in Emacs by providing a convenient way to visualize and explore syntax trees generated by Tree-sitter, facilitating code comprehension and analysis.

treesit-inspect-mode

treesit-inspect-mode in Emacs is a feature designed to provide detailed information and interactive exploration capabilities for syntax trees generated by the Tree-sitter parsing system. Similar to treesit-explore-mode, this mode is particularly useful for developers working with programming languages supported by Tree-sitter who want to gain insights into the structure of their code.

When activated, treesit-inspect-mode displays information about the syntax tree in a separate buffer, typically alongside the original code buffer. This information may include details about the current node under the cursor, such as its type, properties, and position within the syntax tree hierarchy.

One of the primary functionalities of treesit-inspect-mode is to allow users to inspect the properties of individual nodes within the syntax tree interactively.

Overall, treesit-inspect-mode complements the functionality of treesit-explore-mode by offering a focused and detailed view of syntax trees, enabling developers to gain deeper insights into the structure of their code and facilitating tasks such as debugging, code analysis, and comprehension.

Epilogue

So we have seen what tree-sitter and its capabilities inside Emacs. Previously before using tree-sitter for exploring ASTs, I have been using something like AST Explorer for checking my ASTs. Since this comes within Emacs and I don't have to context-switch between the browser and my text editor to work with ASTs. This is really a productivity boost for my day-to-day job.

Tell me what do you think about the tree-sitter in Emacs in the comments section. I am sure there a lot other things you can do with tree-sitter in Emacs other than exploring ASTs.

References:

Striking a Balance: Sensibility vs Convenience in Software Development

Rajasegar Chandran — Thu, 22 Feb 2024 04:44:17 +0000

In the ever-evolving landscape of software development, developers often find themselves at a crossroads between sensibility and convenience. The pursuit of creating efficient and robust software systems sometimes clashes with the desire for quick and easy solutions. Striking the right balance between sensibility and convenience is crucial for delivering high-quality software that meets user expectations and industry standards.

Sensibility in Software Development:

Sensibility in software development refers to the thoughtful consideration of design, architecture, and coding practices. It involves making decisions based on long-term benefits, maintainability, and scalability. Sensible software development aims to create solutions that stand the test of time and adapt to changing requirements.

Code Quality:
Writing clean, well-structured code is a fundamental aspect of sensibility. Code that adheres to best practices is easier to understand, maintain, and debug. Sensible developers prioritize readability and follow coding standards, fostering collaboration among team members and reducing the likelihood of introducing bugs.
Scalability and Performance:
Sensible software design takes into account scalability and performance considerations from the outset. Anticipating future growth and optimizing code for efficiency ensures that the software can handle increased user loads without sacrificing performance.
Security:
Security is a critical aspect of sensibility. A sensible approach involves proactive measures to identify and mitigate potential security risks. Regular code reviews, vulnerability assessments, and adherence to security best practices contribute to a robust defense against cyber threats.

Convenience in Software Development:

Convenience, on the other hand, often involves making choices that prioritize short-term gains, speed of development, and ease of implementation. While convenience can lead to faster initial results, it may introduce challenges in the long run.

Rapid Prototyping:
Convenience plays a significant role in rapid prototyping and iterative development. Using frameworks and tools that expedite the development process allows for quick validation of ideas and concepts. However, it's crucial to reassess and refactor code as the project progresses to maintain sensibility.
Third-party Libraries and Frameworks:
Leveraging third-party libraries and frameworks can enhance convenience by saving development time and effort. However, it's essential to evaluate the long-term support and compatibility of these dependencies to avoid potential issues in future updates.
Short-term Solutions:
Quick fixes and workarounds may be convenient in the short term but can accumulate technical debt over time. Sensible developers weigh the trade-offs and address root causes, ensuring that solutions are not just convenient but sustainable in the long run.

Finding the Balance:

Achieving the right balance between sensibility and convenience is an ongoing challenge for software developers. It requires a thoughtful approach that considers the specific needs of the project, the development team's capabilities, and the overall goals of the software.

Prioritize Sensibility in Core Components:
Critical components of a software system, such as core algorithms, data structures, and security measures, should prioritize sensibility. Investing time and effort in these areas ensures a solid foundation for the entire project.
Use Convenience Wisely:
Convenience can be a valuable ally when applied judiciously. Rapid prototyping, leveraging existing tools, and embracing agile development methodologies can streamline the development process without compromising long-term sensibility.
Regular Refactoring:
Sensible software development includes a commitment to regular refactoring. As the project evolves, developers should revisit code, identify areas for improvement, and refactor as needed. This iterative process maintains sensibility while accommodating the convenience of rapid development.

Conclusion:

In the dynamic field of software development, the tension between sensibility and convenience is inevitable. Successful software projects require a careful balancing act, where sensibility guides the creation of a solid foundation, and convenience is employed thoughtfully to enhance productivity. By embracing both principles, developers can deliver software that not only meets immediate needs but also evolves gracefully to meet the challenges of the future.

Unraveling the Chapelle Salt Trap: A Cautionary Tale in Web Development

Rajasegar Chandran — Mon, 22 Jan 2024 05:59:26 +0000

Web development is a constantly evolving field, and staying updated with the latest trends and technologies is crucial for success. However, amidst the rapid advancements, there are occasional pitfalls that can ensnare even the most experienced developers. In this blog post, we delve into the Chapelle Salt Trap, a real-life scenario that highlights the importance of careful planning and diligent testing in web development projects.

Understanding the Chapelle Salt Trap

The Chapelle Salt Trap refers to a specific challenge often encountered during the development of complex web applications. It takes its name from the French term "chapeau de sel," or "hat of salt," which describes a geological formation where a layer of salt acts as a barrier, trapping hydrocarbons below the surface.

Similar to its geological namesake, the Chapelle Salt Trap in web development represents an unforeseen issue in a software project that hinders progress and impedes the deployment of the desired features. This situation typically arises when a critical flaw or bottleneck is discovered relatively late in the development lifecycle, causing a significant delay or even a complete halt in the project's advancement.

Possible Causes of the Chapelle Salt Trap

Insufficient Planning: One of the key contributors to the Chapelle Salt Trap is inadequate planning. Rushing into development without a solid strategy can lead to incomplete or ambiguous requirements, leaving room for potential issues and confusion down the line.
Over-Reliance on External Dependencies: Integrating external APIs, libraries, or services can boost productivity and add functionality to web applications. However, relying heavily on these external dependencies without thoroughly considering their reliability or scalability can be a recipe for disaster if issues arise unexpectedly.
Inadequate Testing: Failing to implement comprehensive testing procedures throughout the development process is a common culprit behind the Chapelle Salt Trap. Insufficient or improperly executed testing fails to expose crucial bugs or performance issues until late stages, derailing progress and costing valuable time to fix the problems.

Mitigating the Chapelle Salt Trap

While it may not be possible to completely eradicate the Chapelle Salt Trap, there are steps developers can take to minimize the likelihood of encountering this challenge:

Strategic Planning

Investing time in thorough planning, gathering comprehensive requirements, and creating a well-defined roadmap paves the way for a smoother development process. Regular communication with stakeholders and embracing agile methodologies like Scrum can help identify potential roadblocks early on.

Gradual Integration of External Dependencies

Instead of relying entirely on external dependencies, consider gradually integrating them into the project, allowing for better control and flexibility. Create fallback mechanisms for essential functionalities to prevent a complete halt if the dependencies encounter issues.

Gradually integrating external dependencies in a web app is essential to ensure a smooth transition and minimize disruption. It refers to the process of adding external libraries, frameworks, or services to an existing web application incrementally rather than making drastic changes all at once. This approach allows developers to manage complexity, control risks, and maintain the overall stability and performance of the application.

Here are a few key considerations and steps to follow when gradually integrating external dependencies in a web app:

Evaluate and plan: Before adding any external dependencies, carefully assess their relevance, benefits, and impact on your web app. Consider factors like compatibility, maintainability, community support, learning curve, licensing, and performance. Plan the integration roadmap with a clear understanding of the dependencies and their potential risks.
Start small: Begin by integrating a single dependency or a limited set of related dependencies. Choose something that offers immediate value and solves a specific problem in your application. This helps in gaining experience and understanding the impact of the integration on your codebase.
Isolate and modularize: To ensure a smooth integration, identify specific areas or components within your web app where the dependencies will be utilized. Modularize your application to segregate these areas and minimize the impact on the rest of the codebase. This helps in making the integration more manageable and easier to maintain.
Test and validate: Thoroughly test the integration to verify its correctness, maintain existing functionality, and prevent regressions.Make sure to cover unit tests, integration tests, and functional tests to ensure the new dependencies integrate seamlessly with your existing codebase.
Monitor and optimize: Once the integration is complete, continuously monitor the performance and behavior of your web app. Monitor key metrics, such as response time, memory usage, and server load, to identify any potential bottlenecks or issues introduced by the new dependencies. Optimize and fine-tune the integration to maintain optimal performance.
Document and train: Proper documentation and knowledge sharing are crucial to ensure a smooth transition for your development team. Document the integration process, reference materials, and any known issues or workarounds. Conduct training sessions and share best practices to help your team understand and utilize the newly integrated dependencies effectively.

Remember, gradually integrating external dependencies is an iterative process. It requires ongoing maintenance, updates, and occasional refactoring to keep up with evolving dependencies and preserve the stability and performance of your web app.

Comprehensive Testing

Implementing rigorous testing processes at each stage of development is paramount. Utilize unit testing, integration testing, load testing, and user acceptance testing to identify any issues as early as possible, reducing the chances of falling into the Chapelle Salt Trap.

Conclusion

The Chapelle Salt Trap serves as a stark reminder of the challenges that web developers may encounter while developing complex software projects. By recognizing the potential causes and taking preventative measures, web development teams can mitigate the risks and ensure a smoother sail towards project completion.

Consistent planning, judicious use of external dependencies, and a strong focus on comprehensive testing are all vital components in avoiding the Chapelle Salt Trap. By incorporating these best practices into their development processes, developers can minimize the likelihood of encountering unexpected obstacles, ensuring successful project delivery and client satisfaction.

Creating dynamic task runners for your npm scripts in Emacs

Rajasegar Chandran — Wed, 03 Jan 2024 08:58:05 +0000

In this post, I will show you how to create dynamic task runners for your npm projects in Emacs. This is a simple example of how to use Emacs We are going to use prodigy for this example

Usually inside an npm project we run the tasks from the package.json file from the scripts section. A typical package.json file will look like the following

    {
        "name": "alacritty-themes",
        "version": "5.3.1",
        "description": "Themes for Alacritty : A cross-platform GPU-Accelerated Terminal emulator",
        "main": "index.js",
        "bin": {
            "alacritty-themes": "./bin/cli.js"
        },
        "scripts": {
            "commit": "cz",
            "deploy": "git push && git push --tags && npm publish",
            "lint": "eslint .",
            "semantic-release": "semantic-release",
            "test": "mocha --recursive"
        }
    }

So if you want to run the lint task you will run the following in your shell:

    npm run lint

If you are inside Emacs, you probably need to open a new terminal or eshell buffer and manually type the above command. Also if want to run another command in parallel
you need to open a separate buffer and run the command.

So this involves a lot of manual work and it is not a very efficient way to do it. What if we can create a task runner that will run the tasks in parallel? What if we can do that in a way that will be dynamic? That is exactly what we are going to do here using a prodigy service.

Prodigy

What is prodigy? Prodigy is a framework for creating Emacs-based task runners. You can use it to manage external services from within Emacs. You can find more details in the prodigy documentation

To create new prodigy services you need to call the prodigy-define-service function

    (prodigy-define-service
    :command (lambda (&rest args)
               (let ((service (plist-get args :service)))
                 ;; ...
                 )))

Now, let us see how we can achieve this using prodigy in Emacs

    (require 'prodigy)
    (defun my/create-prodigy-service (&optional package-manager)
      "Create new prodigy services based on current package.json"
      (interactive)
      (let ((pkg (json-parse-string (buffer-substring-no-properties (point-min) (point-max)))))
        (maphash  (lambda (key value)
                    (let ((args '())
                          (name (gethash "name" pkg)))
                      (add-to-list 'args key)
                      (add-to-list 'args "run")
                      (prodigy-define-service
                        :name (concat name "-" key)
                        :command (or package-manager "npm")
                        :cwd (file-name-directory (buffer-file-name))
                        :path (file-name-directory (buffer-file-name))
                        :args args
                        :tags '(temp)
                        :stop-signal 'sigkill
                        :kill-process-buffer-on-stop t
                        ))) (gethash "scripts" pkg))
        (prodigy)
        (prodigy-refresh)))

This code is defining a function called my/create-prodigy-service that creates new prodigy services based on the contents of the current package.json file.
You can put this in your init.el file and call it from within Emacs.

Here is a breakdown of the code:

The (interactive) line is important if you plan to use the function interactively, meaning you can call it through a keybinding or by typing M-x and the function name.

In this line, the contents of the current buffer are parsed as a JSON string using the json-parse-string function.
The result is stored in a variable called pkg. The (point-min) and (point-max) functions are used to get the positions of the first and last characters of the buffer, so that buffer-substring-no-properties can extract the contents of the buffer as a string.

Then we use the maphash function to iterate over each key-value pair in the "scripts" hash in the pkg variable. The gethash function is used to get the value associated with the "scripts" key.

And next we define an anonymous function that takes two arguments: key and value. This function will be used as the mapping function for maphash.

Inside the mapping function, a new variable args is initialized as an empty list. Another variable name is assigned the value of the "name" key in the pkg variable.

Then we define a new prodigy service using the prodigy-define-service function. The :name parameter uses the concat function to combine the name and key variables. The :command parameter is set to "npm". The :cwd and :path parameters are set to the directory of the current buffer file. The :args parameter is set to the args list. The :tags parameter is set to '(temp), indicating that the service is temporary. The :stop-signal parameter is set to sigkill to force-stop the service. The :kill-process-buffer-on-stop parameter is set to t to automatically kill the process buffer when the service is stopped.

Finally, prodigy is called to start all defined prodigy services and then prodigy-refresh to refresh the list of services.

Overall, this code creates prodigy services for each script defined in the "scripts" section of the package.json file. It uses the name of the package as part of the service name, and sets the appropriate command, working directory, and arguments for each service.

Here is how it works, open your package.json file situated in the project root folder.
And invoke M-x my/create-prodigy-service

If you want to call inside a lisp file, you can define a function and call it using the following code:

    (my/create-prodigy-service)

By default it will use npm as the default package manager, if you want to use any other package manager, you can specify it as follows:

For using yarn:

    (my/create-prodigy-service "yarn")

For using pnpm:

    (my/create-prodigy-service "pnpm")

Hope you enjoyed the post, if you have any alternate approaches, feedback or queries, please let me know in the comments section.

5 ways to get text from an Emacs buffer

Rajasegar Chandran — Mon, 01 Jan 2024 10:33:39 +0000

Emacs Lisp is a powerful programming language that allows you to customize and extend your Emacs editor. One common task when working with text in Emacs Lisp is extracting or copying text from a buffer. In this blog post, we will explore different ways of getting text from an Emacs buffer.

1. Using `buffer-substring`

The buffer-substring function is a simple and straightforward way to extract text from a buffer. It takes two arguments: start and end positions, and returns the corresponding text.

(let ((start (point-min))
      (end (point-max)))
  (buffer-substring start end))

In this example, we extract the entire buffer by setting the start position to (point-min) and the end position to (point-max).

2. Using `buffer-substring-no-properties`

If you want to exclude text properties (such as font face or color) from the extracted text, you can use the buffer-substring-no-properties function. It works the same way as buffer-substring.

(let ((start (point-min))
      (end (point-max)))
  (buffer-substring-no-properties start end))

3. Using `buffer-string`

The buffer-string function returns the entire contents of the current buffer as a string. This is a convenient way to extract text when you don't need to specify start and end positions.

(buffer-string)

4. Using region

If you have an active region in your Emacs buffer, you can use the region-beginning and region-end functions to get the start and end positions of the selected text. You can then use buffer-substring or buffer-substring-no-properties to extract the text.

(let ((start (region-beginning))
      (end (region-end)))
  (buffer-substring start end))

5. Using `thing-at-point`

The thing-at-point function allows you to retrieve different types of text at the current point. You can specify the type of thing using the thing argument. For example, to get the word at point, you can use (thing-at-point 'word).

(thing-at-point 'word)

You can also combine thing-at-point with bounds-of-thing-at-point to retrieve the start and end positions of the thing.

(let ((bounds (bounds-of-thing-at-point 'word)))
  (buffer-substring (car bounds) (cdr bounds)))

These are just a few examples of different ways to extract text from an Emacs buffer in Emacs Lisp. Depending on your specific use case, you may choose a different approach. Emacs Lisp provides a wide range of functions and tools to manipulate text, giving you the flexibility to perform various text-related operations in Emacs.

If you know any other way of obtaining the text from the buffer, please let us know in the comments section. I would love to learn more tricks about Elisp functions for getting text from the buffer.

Debugging rules: Change one thing at a time

Rajasegar Chandran — Sat, 07 Oct 2023 13:33:31 +0000

Altering elements individually poses its own set of challenges. When modifications occur in pairs, the potential arises for subtle errors that closely resemble the initial issues. This leaves you in a perplexing situation, unsure whether the correction wasn't applied, if the correction inadvertently introduced a similar problem, or if the original error persists along with a comparable new one. To navigate this complexity, adhere to simplicity: implement just one change at a time.

Opt for a focused approach of making singular adjustments. Discard the notion of a shotgun strategy; instead, equip yourself with a precise rifle. This method proves more effective in resolving bugs, as indiscriminate alterations can disrupt otherwise functional components.

Moreover, pinpointing the exact failure allows you to address only that specific issue. Essentially, if you believe a wide-ranging approach is necessary, the underlying problem likely lies in the lack of clarity regarding the target.

In numerous instances, the inclination to modify various components within the system arises with the aim of assessing their impact on the issue at hand. However, this tendency often serves as a red flag, indicating a reliance on guesswork rather than leveraging instrumentation effectively to comprehend the underlying dynamics. Instead of diligently observing the natural occurrence of the failure, there's a shift towards altering conditions, potentially concealing the initial problem and potentially giving rise to additional issues.

It's more effective to remember to do
something than to remember not to do something.

Isolate the key factor

The essence of effective debugging lies in pinpointing the critical factor by narrowing the focus to a specific section of code where a potential issue may be situated. This targeted approach empowers developers to efficiently recognize and address problems, leading to time and effort savings. By honing in on a particular segment, be it a function or module, the debugging process gains precision and effectiveness.

For a robust technique to zero in on the suspicious region of the code, systematically eliminate portions of the program and observe if the error persists. If the issue disappears, it indicates that the problem lies in the removed part; if it persists, the problem resides in the retained portion.

Consider whether this exhibits a familiar pattern. Recognizing the phrase "I've seen that before" often marks the inception of understanding, if not the complete solution. Common bugs tend to exhibit distinctive signatures.

Change one test at a time

Occasionally, altering the test sequence or adjusting certain operational parameters can induce a problem to manifest more consistently, offering a clearer view of the failure and providing valuable insights into the underlying issues. Nevertheless, it remains crucial to adhere to the principle of modifying only one element at a time. This ensures precise identification of the parameter responsible for the observed effect. If a modification appears ineffective, promptly revert it to its original state.

Compare it with a good one

Once you possess a method to induce a system to either fail or remain functional, even if the occurrence is sporadic, you find yourself in an excellent position to function as a differencing engine.

Be a differencing engine! See the world! Or, at least, see the differences!

By examining two scenarios, one experiencing failure and the other functioning correctly, compare various aspects such as scope traces, code traces, debug output, and status windows or any other instrumented elements.

If a multitude of code changes occurred between the two tests or if distinct scenarios were set up, comparing the tests can become challenging. Constantly addressing differences unrelated to the bug might obscure the identification of the actual issue. It is essential to minimize disparities between the two traces to isolate the bug. Aim to obtain logs from the same machine during consecutive attempts, avoiding variations like different machines, software, parameters, user input, days, or environments.

This doesn't imply that you shouldn't instrument elements unrelated to the bug. Since the relevance of certain aspects to the bug is not yet clear, comprehensive instrumentation is crucial. Even if an aspect is unrelated, it will manifest consistently in both logs, allowing you to swiftly bypass irrelevant data during analysis.

Identifying problematic elements isn't a skill easily imparted to beginners or automatable through programming. What you seek is ever-changing and distinct from previous instances. Navigating through irrelevant disparities induced by timing or other factors requires a significant level of knowledge and intelligence. This level of understanding surpasses the capabilities of a novice, and the required discernment goes beyond the capabilities of software.

When confronted with an extensive and intricate log, there may be a temptation to focus solely on suspect areas, which is acceptable if an issue is promptly discovered. However, in cases where no immediate revelation occurs, be prepared to examine the entire log, as the location of pertinent differences remains uncertain.

If the bad ones all have something that the good ones don't, you are onto the problem.

Examine the most recent change

Identifying the most recent alteration is crucial. When adhering to the practice of modifying only one aspect at a time during the evolution of a program, the bug is likely either within the new code or brought to light by it. Scrutinizing recent changes is instrumental in localizing the issue. If the bug surfaces in the new version but not in the old one, it implicates the new code as part of the problem.

At times, the distinction between a functional system and a malfunctioning one can be traced back to a design alteration. In such cases, a once-reliable system starts exhibiting failures. Pinpointing the version that initially triggers the failure, even if it entails testing progressively older versions until the issue dissipates, is beneficial. Once the problem disappears, progress to the subsequent version and confirm the recurrence of the failure. This process effectively narrows down the problem to alterations between those two versions, providing a focused perspective on the issue, assuming the change wasn't a complete overhaul of the system.

Typically, new designs undergo testing before being shipped due to the common occurrence of faults in their initial iterations. Compatibility issues often arise when a new design in one section does not align well with another section that was functioning perfectly.

However, some cases prove challenging. Occasionally, a longstanding issue only manifests itself when other changes occur. The introduction of new code or a hardware revision may create conditions causing a previously reliable subsystem to fail. It's akin to discovering a hole in the subsystem that was always there, but you never ventured close enough to fall through it before. While fixing the immediate bug leading to the hole might be tempting and sometimes necessary for short-term solutions, the ultimate goal is to address and seal the underlying issue.

When confronted with a perplexing new error, the root cause is often linked to recently altered code, whether it's entirely new or modifications to existing code. If unable to identify a defect, running an older version of the program can help determine whether the error persists. If it doesn't, it indicates that the error lies in the new version or stems from an interaction with the changes made in the new version.

Scrutinize the differences between the old and new versions

Examine the version control log to identify recent code modifications. If this is not feasible, employ a differential tool to compare alterations between the previous functional source code and the current malfunctioning source code.

Seeking predictability in your routine is essential. Eliminate modifications that did not yield the anticipated results, as they likely introduced unexpected consequences.

Ember Language Server in Emacs

Rajasegar Chandran — Thu, 05 Oct 2023 04:13:45 +0000

In this post we are going to see how we can set up the language server for Ember in Emacs.

A language server is a program that provides language-specific features for code editors or integrated development environments (IDEs). It acts as a server, interacting with the editor to offer services such as code completion, error checking, and other language-specific features. In summary, language servers enhance the development experience by providing consistent language support, intelligent features, and improved productivity across various code editors and IDEs.

Ember.js

Ember.js stands out as a robust and proven JavaScript framework designed to facilitate the development of contemporary web applications. Equipped with comprehensive tools, it empowers developers to create feature-rich user interfaces that seamlessly function across various devices. Widely recognized as a framework tailored for ambitious web developers, Ember.js offers a productive environment for building sophisticated web applications.

Emacs

GNU Emacs stands as a freely available text editor crafted by Richard Stallman, the founder of the GNU Project. Originating from the Emacs editor designed for Unix operating systems, GNU Emacs has played a pivotal role in the GNU project and serves as a flagship initiative within the free software movement. Its defining characteristic is encapsulated in the tagline "the extensible self-documenting text editor."

Ember Language Server

The Ember Language Server (ELS) implements the Language Server Protocol for Ember.js projects. ELS enables editors to provide features like auto complete, goto definition and diagnostics. To get these features, you have to install the plugin for your editor.

For this post we are going to use a particular version of ELS created by Alex Kanunnikov. You can find the code here in ember-language-server

You need to clone this in your local machine and build it. Then we use the build artifacts to start the language server automatically from Emacs using the LSP tooling.

git clone https://github.com/lifeart/ember-language-server

There is also another version of language server provided by the official Ember community which you can found ember-tooling/ember-language-server

emacs-lsp-mode

The lsp-mode package provides the Language Server Protocol support for Emacs. It is community driven, fully featured, performant, flexible and easy to configure. It supports all features in Language Server Protocol v3.14. You can choose between full-blown IDE with flashy UI or minimal distraction free. It just works out of the box and automatically upgrades if additional packages are present.

Before configuring the lsp-mode for Ember we need to define a new major mode called hbs-mode for editing Handlebars templates. Here's how we do it:

(define-derived-mode hbs-mode web-mode "Handlebars mode" "Major mode for handlebars")
(add-to-list 'auto-mode-alist '("\\.hbs\\'" . hbs-mode))

In the above code we are defining a new major mode named hbs-mode by deriving it from the existing mode web-mode. The string "Handlebars mode" is the mode's user-friendly name, and "Major mode for handlebars" is its documentation string. In Emacs, major modes are used to provide specialized editing features for specific types of files. In this case, hbs-mode is specifically tailored for editing Handlebars templates.

Next we add an entry to the auto-mode-alist variable, which is a list of filename patterns and corresponding major modes. When you open a file, Emacs checks this list to determine which major mode to use based on the file's extension. The added entry specifies that any file with the extension ".hbs" should be opened in hbs-mode. The regular expression "\\ .hbs\\'" is used to match file names ending with ".hbs".

The dot (.) in the regular expression is a wildcard that matches any character, and the double backslash (\\) is used to escape the dot and match it literally. The single-quote (') in the regular expression matches the end of the string.

In short, this code sets up a new major mode called hbs-mode for editing Handlebars templates in Emacs. It also ensures that any file with the extension ".hbs" will automatically use this major mode when opened in Emacs.

You need to add the following code to your Emacs configuration file to get the language server working.

    (with-eval-after-load 'lsp-mode
     (add-to-list 'lsp-language-id-configuration
       '(hbs-mode . "hbs"))
     (lsp-register-client
      ;; Git clone language server from https://github.com/lifeart/ember-language-server/tree/component-context-info-origin
      ;; And build it
       (make-lsp-client :new-connection (lsp-stdio-connection (list "node" (expand-file-name "~/www/ember-language-server/lib/start-server.js") "--stdio"))
                        :activation-fn (lsp-activate-on "hbs")
                        :server-id 'ember-language-server)))

Let me explain what the above code does.

The macro (with-eval-after-load 'lsp-mode ) ensures that the enclosed code is executed after the lsp-mode package has been loaded. It is used to set up configurations or additional actions related to the lsp-mode package.

The line (add-to-list 'lsp-language-id-configuration …) adds an entry to the lsp-language-id-configuration variable, which is used to configure language identifiers for the Language Server Protocol (LSP). In this case, it associates the language identifier 'hbs-mode' with the string "hbs".

The function call (lsp-register-client …) registers a new LSP client for handling the Ember Language Server. The :new-connection property specifies how to establish a connection to the language server. Here, it uses lsp-stdio-connection with a list of arguments. It's starting the server using Node.js and pointing to the start-server.js file of the Ember Language Server. The :activation-fn property specifies when to activate the language server. It uses lsp-activate-on with the argument "hbs", meaning the server should be activated when working with files of type "hbs". The :server-id property associates a unique identifier with this server configuration. In this case, it's set to 'ember-language-server'.

In summary, this code is configuring Emacs to use the Ember Language Server for Handlebars files (hbs-mode). The language server is started as a new process using Node.js, and it will be activated whenever a Handlebars file is being edited. The server configuration is registered with the identifier 'ember-language-server'.

So this is the final and full code for configuring lsp-mode for Ember handlebars in Emacs


    (define-derived-mode hbs-mode web-mode "Handlebars mode" "Major mode for handlebars")
    (add-to-list 'auto-mode-alist '("\\.hbs\\'" . hbs-mode))

    (with-eval-after-load 'lsp-mode
    (add-to-list 'lsp-language-id-configuration
        '(hbs-mode . "hbs"))
    (lsp-register-client
    ;; Git clone language server from https://github.com/lifeart/ember-language-server/tree/component-context-info-origin
    ;; And build it
        (make-lsp-client :new-connection (lsp-stdio-connection (list "node" (expand-file-name "~/www/ember-language-server/lib/start-server.js") "--stdio"))
                        :activation-fn (lsp-activate-on "hbs")
                        :server-id 'ember-language-server)))

eglot

Next we try to achieve the same with another LSP tool in Emacs called eglot

Eglot is the Emacs client for the Language Server Protocol (LSP). The name “Eglot” is an acronym that stands for “Emacs Polyglot”. Eglot provides infrastructure and a set of commands for enriching the source code editing capabilities of Emacs via LSP. Eglot itself is completely language-agnostic, but it can support any programming language for which there is a language server and an Emacs major mode.

    (add-hook 'hbs-mode-hook 'eglot-ensure)
    (with-eval-after-load 'eglot
      (add-to-list 'eglot-server-programs
                   '(hbs-mode . ("node" "/Users/rajasegarchandran/www/ember-language-server/lib/start-server.js" "--stdio"))))

Let's break down the code:

First we add a function (eglot-ensure) to the hbs-mode-hook. In Emacs, a "hook" is a way to run custom code when a certain mode is activated.In this case, it ensures that the eglot server is started when hbs-mode is activated.

Now we delay the execution of the code inside it until after the eglot package has been loaded. This is useful because it ensures that the configuration is applied after the eglot package is available. Next we add an entry to the eglot-server-programs list, which specifies the command to start the language server for a particular mode. Then we associate the hbs-mode with the command to start the Ember Language Server for Handlebars. The server is started using the "node" executable, and it runs the specified JavaScript file (start-server.js) with the "--stdio" option.

The command node and its arguments that will be executed when the language server for Handlebars is started.
It launches the Node.js interpreter with the specified JavaScript file and tells it to use the standard I/O for communication.

We basically ensure that the eglot server is started automatically when hbs-mode is activated, and it specifies the command to start the language server for Handlebars.

Now you know how to configure and register the Ember Language Server for handling Handlebars (hbs) files within the Emacs text editor.

Debugging rules: Quit thinking and look

Rajasegar Chandran — Sat, 09 Sep 2023 04:05:43 +0000

It is a capital mistake to theorize before one has data.

Observing the failure firsthand is essential. When you make assumptions about the problem's cause, you often end up trying to fix something unrelated to the actual bug. This not only results in an ineffective solution but also consumes valuable time and resources, possibly causing additional issues. Avoid this approach.

Instead, stop overthinking and start observing. This is among the most valuable advice you can give to anyone dealing with debugging.

Engineers are inherently analytical thinkers. They enjoy the intellectual challenge, which is why they chose engineering over physical labor. While engineers generate ingenious ideas, there are more ways for things to go wrong than even the most imaginative engineer can anticipate. So, why do we believe we can solve problems purely through thought? Because we are engineers, and thinking is more convenient than observing.

Observing is demanding. It is often, if not always, more complex than we would prefer. In the realm of software, observing entails setting breakpoints, inserting debug statements, monitoring program variables, and inspecting memory.

After you have dis-proven your initial assumptions, you are still left with the task of identifying the bug. You end up with the same workload as before, but now you have less time. This is far from ideal unless you subscribe to the notion that the sooner you fall behind, the more time you have to catch up. Therefore, here are some guidelines to help you prioritize observation over premature speculation.

See the failure

It appears self-evident that to identify a failure, one must witness the failure occurring firsthand. When we observe a bug, what we are actually seeing is the aftermath of the failure. To effectively debug, it is imperative to scrutinize the failure in intricate detail. Many issues can be easily misconstrued if you cannot observe the entire sequence of events as they unfold. Without a comprehensive view, you may inadvertently address a problem you've merely speculated about, when in reality, a completely different element has malfunctioned. The true nature of the problem becomes evident only when someone observes it in action.

Ensure that you have a clear understanding of the precise issue at hand. In most cases, the act of observation is significantly faster than relying on hasty guesswork shortcuts, as these shortcuts often lead to dead ends.

See the details

The extent of observation needed is usually quite limited. In most cases, with each instance of examining the system to observe the failure, you gain additional insights into the nature of the malfunction. This enables you to determine where to delve deeper to acquire more detailed information. Gradually, you accumulate sufficient details to justify an examination of the system's design, aiming to pinpoint the root cause of the issue.

When should you transition from observation to analysis? Continue the process of observation until the visible failure narrows down to a manageable number of potential causes that warrant further examination.

The Streetlight effect

There's something called "The Streetlight effect". It's a metaphor for knowledge and ignorance. The streetlight effect, or the drunkard's search principle, is a type of observational bias that occurs when people only search for something where it is easiest to look.

Build instrumentation in

In the realm of software development, the initial layer of built-in instrumentation typically involves compiling the code in debug mode, enabling you to observe the program's execution using a source code debugger.

Having a higher volume of status messages is beneficial, but it's essential to incorporate a mechanism that allows you to selectively enable or disable specific messages or message types. This flexibility enables you to focus your attention on the messages relevant to diagnosing a particular issue.

It's crucial to incorporate debugging considerations right from the outset of the design process. Ensure that instrumentation is a fundamental component of your product requirements. Incorporate hooks for instrumentation in every functional specification and API definition. Include the debug monitor and analysis filter as integral components of your standard utility toolkit.

Furthermore, aside from simplifying the eventual debugging process, contemplating the instrumentation needs also aids in designing the system more effectively and mitigating some of the potential bugs from arising in the first place.

Add instrumentation on

If you weren't able to incorporate instrumentation during the initial development, at the very least, consider adding it afterward. Utilize a debugger to gain an internal perspective on your code.

Don't be afraid to dive in

If a bug is present in the code, you'll eventually need to recompile the software to rectify it. Consequently, you should also be open to recompiling the software to initially identify the bug. Create a debug version that allows you to access the source code and incorporate new debugging statements to inspect the crucial parameters you need to examine.

Watch out for Heisenbugs

Heisenberg emerged as one of the trailblazers in the field of quantum physics. While delving into the intricate world of extremely light and minuscule atomic particles, he recognized a fundamental principle: when dealing with these particles, you can either measure their precise location or their trajectory, but the more accurately you determine one of these aspects, the more you perturb the other.

A HeisenBug is a glitch that exhibits a peculiar characteristic—it responds to the act of observation. For instance, it might mysteriously vanish when the program is in debug mode.

The challenge arises from the fact that obtaining an accurate measurement is hindered because the tools used for observation are an integral part of the system. Your testing instruments inherently impact the system undergoing examination.

Even a debugger can introduce some degree of timing variation, and any form of instrumentation, to varying extents, influences the system's behavior. This is an unavoidable reality, and it's crucial to bear this in mind so that you're not caught off guard by these effects. Additionally, some methods of instrumentation are less intrusive than others.

Remarkably, even minor alterations can perturb the system enough to obscure the bug entirely. Instrumentation is one such alteration. Therefore, after implementing instrumentation in a malfunctioning system, it's imperative to recreate the failure to ascertain that Heisenberg's principle is not inadvertently confounding your efforts.

Guess only to focus the search

Guessing can be a valuable tool, particularly when you have a strong grasp of the system. Your educated guesses might even come close to the mark. However, it's crucial to use guesswork as a means to narrow down your search. You must still validate your assumptions by witnessing the failure before attempting to rectify it.

When you encounter an unexpected bug, it's essential to reevaluate the certainties you hold dear. The degree of surprise you experience when something goes awry is directly linked to the level of trust and confidence you place in the code that's running. Therefore, when confronted with an "astonishing" failure, it's imperative to recognize that one or more of your foundational assumptions are incorrect.

In the face of an unforeseen bug, your task extends beyond mere resolution; you must also investigate why this issue went unnoticed until now. Ensure that whatever transpired, you have mechanisms in place to detect it if it occurs again.

Furthermore, if the bug stems from misconceptions held by a team member, it's essential to engage in a collective discussion about the problem. If one person misunderstands, it's possible that others share the same misconception.

Hence, it's advisable not to place excessive trust in your initial guesses; often, they can lead you down the wrong path and prove to be significantly off the mark. If meticulous instrumentation fails to corroborate a particular assumption, it's time to step back and reconsider your guesswork.

Debugging Rules: Keep an Audit Trail

Rajasegar Chandran — Sat, 19 Aug 2023 04:50:46 +0000

Debugging proves to be a challenging task that often demands extended and uncertain periods for resolution. Thus, the objective revolves around minimizing the necessity for extensive debugging. Skillful programmers acknowledge that they invest an equal amount of time in debugging as they do in actual coding, prompting them to extract lessons from their errors. Each identified bug serves as an opportunity to grasp methods for averting analogous issues in the future or swiftly identifying them if they arise once more.

"There is no branch of detective science which is so important and so much neglected as the art of tracing footsteps"

Occasionally, the seemingly trivial aspects can hold the essential clue to triggering a bug. Elements that appear unimportant to the QA person could hold significance for the troubleshooter. Likewise, what appears evident to the QA person might elude the person attempting the fix. Therefore, meticulous attention to every detail is crucial, as there's a possibility that seemingly insignificant factors could carry hidden importance.

Write down what you did, in what order, and what happened

Maintain a record of actions taken. While delving into an issue, document your procedures, their sequential arrangement, and the ensuing outcomes. Consistently adhere to this practice. Think of it as akin to embedding instruments within the software or hardware - here, you're incorporating instrumentation into the testing process. This approach enables you to discern each undertaken step and its corresponding outcome. Such meticulous tracking aids in pinpointing the precise step deserving of attention during the debugging phase.

The Devil is in the Details

Recognize that every detail possesses potential significance. Regrettably, although the worth of maintaining an audit trail is commonly acknowledged, the extent of required specificity often isn't, leading to the omission of critical information. What type of system was in operation? How did the sequence of events unfold prior to the malfunction? And occasionally, what precisely constituted the failure itself?

The essence lies in augmenting any debug traces or logs with supplementary conditions and symptoms that might not be explicitly present in the logs. If you can establish correlations between symptoms and timestamps, the efficacy is enhanced further.

Maintain a precise and uniform approach when articulating descriptions. You can't commence the process of problem-solving until you have a firm grasp on the fundamental symptoms. Another noteworthy aspect is not solely comprehending what transpired, but also quantifying the extent of the occurrence. The pivotal element resided within a detail that one would typically overlook. Yet, a disposition to scrutinize and meticulously document every aspect is imperative.

Correlate

Drawing connections between symptoms and other symptoms or debug data proves highly advantageous. In systems characterized by intercommunication among multiple devices, maintaining records for both systems, complete with accurately synchronized timestamps, holds significant value. This reservoir of information is tremendously beneficial. Numerous bugs have been unearthed through the process of correlating symptoms with human timelines.

Audit Trails for Design are also Good for Testing

Exerting control over tools is paramount for precisely reproducing a version, and ensuring its presence is imperative. Unidentified deviations in tools can result in exceedingly peculiar outcomes.

The Shortest Pencil is longer than the longest memory

Relying on your memory for specifics is inadvisable; instead, document them in writing. Placing trust solely in your memory leads to several eventualities. You'll inevitably overlook the details that seemed inconsequential in the moment, which ironically turn out to be pivotal.

Additionally, you'll omit details that might not have held significance for you but could hold importance for others tackling different issues later on. This approach limits your ability to effectively convey information unless done verbally, causing unnecessary time wastage for everyone, assuming you're present to discuss it. Furthermore, retaining a comprehensive recollection of events, their sequence, and their interrelationships becomes an intricate challenge. This information, however, is fundamental.

Document the details by putting them in writing. Opt for digital documentation in a simple and easy to consume format to facilitate the creation of backup copies, seamless attachment to bug reports, effortless distribution to others, and the potential for subsequent analysis through automated tools. Jot down your actions and their corresponding outcomes. Preserve your debug logs and traces, and supplement them with contextual incidents and impacts that might not be explicitly captured. Record your hypotheses and solutions. Leave no aspect undocumented.

Write it down. No matter how horrible the moment , make a memorandum of it.

Keep a notepad by your desk

One factor leading programmers into a quandary during debugging sessions is delving excessively into fruitless routes. Compile a roster of strategies to attempt, and if a particular method proves ineffective, transition to the subsequent alternative.

Maintaining an audit trail during debugging offers several key advantages:

Comprehensive Tracking: An audit trail chronicles your investigative steps, enabling you to retrace your actions and decisions. This tracking ensures transparency and accountability in the debugging process.
Efficient Collaboration: Sharing an audit trail with colleagues or teammates enhances collaboration. Others can comprehend your thought process, aiding in quicker problem resolution and minimizing duplicated efforts.
Accurate Reproduction: An audit trail facilitates the recreation of issues in controlled environments. By following the documented steps, you increase the likelihood of replicating the problem accurately, leading to more effective troubleshooting.
Diagnosing Root Causes: Analyzing the audit trail helps you pinpoint the exact moment or sequence of events that triggered the bug. This insight is invaluable in identifying underlying issues and formulating precise solutions.
Holistic Understanding: The trail captures not only the immediate actions but also the context and environmental conditions. This comprehensive understanding is crucial for grasping the bigger picture of the problem.
Learning and Improvement: Reviewing past audit trails enables you to learn from previous experiences. Understanding the path taken to identify and rectify issues can help you avoid similar pitfalls in the future.
Adaptable Problem-Solving: With an audit trail, you can easily switch between different approaches without losing your progress. If one avenue proves unsuccessful, you can retrace your steps and pursue alternate solutions.
Effective Documentation: The audit trail serves as documentation of your debugging efforts. This documentation can be used for future reference, training new team members, and building a knowledge base.
Optimized Time Management: Instead of aimlessly retracing your steps, you can refer to the audit trail to quickly resume your investigation. This prevents wasted time and expedites the resolution process.
Data-Driven Insights: By recording observations, hypotheses, and results, you're gathering data that can provide insights into recurring issues, patterns, and potential improvements in the development process.

In summary, maintaining an audit trail during debugging promotes transparency, collaboration, and systematic analysis. It's an indispensable practice that enhances problem-solving efficiency and contributes to overall software quality.

If the process of hunting for a bug continues for an extended period, you'll find it challenging to keep a clear record of your attempted solutions and the insights you've gained. By documenting your testing procedures and outcomes, the chances of missing crucial details or mistakenly assuming you've explored a certain avenue diminish. The act of jotting down your thoughts will enhance your recall of the issue when facing a similar situation in the future, and it will also be valuable when articulating the problem to another person.

Debugging Rules: Make it Fail

Rajasegar Chandran — Tue, 15 Aug 2023 05:54:01 +0000

This post is third in the series of posts about the rules of debugging.

Adopting a methodical strategy for identifying and rectifying errors is essential for achieving success. The initial and primary phase of this approach involves achieving consistency in the failure. Direct your debugging efforts to ensure that each test conducted propels you incrementally closer to a solution.

The Scientific Method of Debugging

In his seminal book, Code Complete, Steve McConnell, simply draws parallels in debugging based on the Scientific Method, which is the process of discovery and demonstration necessary for scientific investigation.

Based on the Scientific approach, an effective debugging approach would consist of the following steps:

Stabilize the error
Locate the source of the error
Fix the defect
Test the fix
Look for similar errors

As you can see, the initial phase hinges on achieving repeatability. Diagnosing a defect becomes more manageable when it can be stabilized, ensuring consistent and reliable occurrence. Diagnosing a defect that lacks reliability in its occurrence becomes a formidable challenge. Establishing predictability for an intermittent defect ranks among the most demanding endeavors in the debugging process.

Stabilize the Error

An error that manifests unpredictably is typically rooted in either initialization discrepancies or timing irregularities. The process of stabilizing such an error encompasses more than merely identifying a test case that triggers the error. It entails refining the test case to its simplest form while still yielding the error.

3 reasons so you can

There are three primary reasons why you are trying to make it fail consistently:

Look at it

In order to see it fail, you have to be able to make it fail. You have to make it fail as regularly as possible.

Focus on the cause

Knowing under exactly what conditions it will fail helps you focus on probable causes.

Tell if you've fixed it

Once you think that you've fixed the problem having a surefire way to make it fail gives you a surefire test of whether you fixed it.

Just Do it "again"

However, how can you induce a failure? Well, a straightforward approach involves utilizing the system under normal conditions and observing instances of incorrect behavior. Naturally, this process aligns with the concept of testing; however, the crucial aspect lies in the ability to reproduce the failure repeatedly, extending beyond the initial occurrence. While a comprehensively documented testing procedure offers advantages, the primary focus should revolve around maintaining the mindset that a solitary failure is insufficient.

Examine your actions and replicate them deliberately. Record each action as you proceed. Subsequently, adhere to your documented procedure to verify its consistent capacity to trigger the error. Nonetheless, certain scenarios exist where orchestrating failure could result in harm or undesirable consequences. In such instances, perpetuating the same mode of failure consistently might not be prudent. Adjustments must be made to minimize the extent of potential damage, while striving to retain the essence of the original system and sequence to the greatest extent possible.

Start at the beginning

Frequently, the necessary actions are concise and minimal. On occasion, the order of events might be uncomplicated, yet a substantial amount of preparatory work is essential.

Bugs can depend on a complex state of the machine

Due to the potential for bugs to rely on intricate machine states, it is imperative to meticulously observe and document the machine's state before initiating your sequence.

Stimulate the failure

If the failure sequence involves numerous manual actions, streamlining the process through automation can prove advantageous.

In numerous instances, the failure manifests itself only after a significant number of iterations, making it beneficial to employ an automated testing mechanism throughout the night.

Simulating vs Stimulating

Distinguishing between inducing failure (good) and duplicating failure artificially (good) is crucial. It is acceptable to replicate the circumstances that lead to failure, but it's advisable to steer clear of artificially reproducing the failure mechanism itself.

In instances involving intermittent bugs, you might speculate that a specific underlying mechanism is responsible for the failure. In response, you could construct a configuration that exercises this mechanism and subsequently observe a higher frequency of failures. Alternatively, if you encounter a bug discovered at a remote location, you might attempt to establish a comparable system in your own environment. In either scenario, your objective is to simulate the failure – essentially, to recreate it – albeit through an alternate approach or on a distinct system.

Don't simulate the failure

When attempting to deduce the failure mechanism, simulations frequently prove ineffective. This is typically due to either an inaccurate assumption or the alteration of conditions during testing. As a result, your simulated setup might exhibit consistent flawless performance or, more problematically, encounter a fresh failure mode that diverts your attention from the original bug you were initially investigating.

You have enough bugs already; don't try to create new ones.

You're already dealing with a sufficient number of bugs; there's no need to intentionally introduce new ones. Utilize instrumentation to examine the source of the issue, but refrain from altering the underlying mechanism as it is the very cause of the failure.

Attempting to replicate a bug by inducing it on a similar system can be beneficial, but within certain boundaries. If a bug can be reproduced on multiple systems, it signifies a design flaw rather than an isolated system malfunction. Recreating the issue on specific configurations while excluding others aids in narrowing down potential root causes. However, if you encounter difficulty in swiftly reproducing the bug, avoid modifying your simulation to force its occurrence. Doing so would result in generating new configurations rather than examining a copy of the one that failed.

When dealing with a system that experiences regular or intermittent failures, focus your efforts on addressing the problem within that specific system and configuration.

Remember, this does not imply that you should avoid automating or intensifying your testing to trigger the failure. Automation can expedite the occurrence of intermittent issues, while intensification can make subtle problems more evident. Both methods contribute to provoking the failure without artificially simulating the malfunctioning mechanism. Any adjustments made should operate at a higher level, not altering how the system fails, but rather influencing its frequency. However, exercise caution to prevent excessive modifications that could potentially introduce new complications.

The Uncontrolled condition

Identify the sporadic occurrence of an uncontrolled condition. The challenge of "Making it Fail" becomes significantly greater when the failure transpires intermittently. Many intricate challenges exhibit intermittent patterns, which occasionally deter us from strictly adhering to this principle, given its inherent complexity. While you might precisely understand the steps that led to the initial failure, reproducing it consistently remains elusive – perhaps occurring only once in every five, ten, or even a hundred attempts.

The critical aspect to recognize is that while you possess a clear understanding of the actions that triggered the failure, you lack exhaustive knowledge of all the precise conditions. Unnoticed or uncontrollable factors invariably play a role. Gaining mastery over these diverse conditions equips you to induce the failure consistently. However, circumstances may arise where certain conditions remain beyond your control.

The Signature

It's crucial to possess the ability to closely examine the occurrence of the failure. In situations where the failure isn't consistent, you must thoroughly analyze it whenever it does happen, disregarding the numerous instances when it doesn't. The pivotal strategy involves gathering comprehensive data during each run, allowing you to conduct an in-depth analysis once the failure has been confirmed. This can be achieved by generating extensive system output while it's operational and archiving this information within a designated "debug log" file.

By scrutinizing the accumulated data, you can readily contrast a failed run with a successful one. If you manage to capture the relevant information, you'll likely discern discernible distinctions between instances of successful execution and those resulting in failure. Pay special attention to the factors unique to the failure cases. These distinctions form the basis of your investigation during the debugging process.

Even in scenarios where the failure occurs intermittently, this approach enables you to identify and document the occurrences systematically, thereby allowing you to address them as if they were consistently happening.

Barking up the wrong tree

The second rationale behind inducing failure is to gain insights into its underlying cause. With intermittent issues, you might begin noticing patterns in your actions that appear connected to the failure. While this can be useful, it's important to exercise caution and not become excessively fixated on these patterns.

In cases of random failures, obtaining a statistically significant number of samples to determine whether seemingly minor actions, such as clicking a button with your left or right hand, truly affect the outcome, is often unfeasible.

Frequently, coincidences may lead you to believe that one condition increases the likelihood of the problem compared to another. This can lead you down a path of investigating differences between conditions that might not actually be directly responsible for the issue, resulting in wasted effort.

However, this doesn't discount the possibility that the observed coincidental differences are somehow related to the bug. Yet, if these differences don't exert a direct influence, they can easily be overshadowed by other random factors, making it challenging to deduce a clear connection.

By accumulating a substantial volume of information, you can distinguish elements consistently associated with the bug from those never linked to it. These are the aspects you should concentrate on while exploring plausible causes of the problem.

Undeniably, randomness complicates the process of confirming a fix. For instance, if the test reveals a 10% failure rate, and your intervention reduces it to 3% — but you cease testing after 28 attempts — you might believe the issue is resolved, even though it isn't.

While employing statistical testing is beneficial, it's even more advantageous to identify a sequence of events invariably linked to the failure, even if the occurrence of the sequence is intermittent. When the sequence arises, failure is guaranteed. Therefore, after implementing a potential fix, continue testing until the sequence transpires. If the sequence manifests without the associated failure, you've successfully rectified the bug. Don't prematurely conclude after 28 attempts if the sequence hasn't surfaced yet.

Black swans

It is easy to just neglect the warning signs and ignore the arguments by other people who insist on the existence of the bugs like customers, quality assurance people. You ego can stand in your way from understanding and perceiving the unknown nature of the bug. But you can't simply deny the possibility of the occurrences.

Know that "that" can happen

The absence of evidence does not mean the evidence of absence. Remember, people simply denied the existence of Black swans until they see one. The world of software and hardware is a type of Extremistan, where there is a high probability of unexpected events to happen. And when you see one Black swan, it's time to ditch your assumptions and think about devising a completely new strategy to find new ones.

Never throw away a debugging tool

Occasionally, a testing tool can find application in various debugging scenarios. When designing such a tool, it's crucial to consider its potential for reuse and ensure it remains maintainable and adaptable. Achieving this entails employing sound engineering practices, creating comprehensive documentation, and incorporating it into your source code control system. Integrate it seamlessly into your systems to ensure accessibility in real-world scenarios. Refrain from treating it as a disposable tool; your initial assumption of its limited utility might be inaccurate.

Occasionally, a tool proves so invaluable that it could even be marketable; there are instances where companies have shifted their business focus upon realizing that the tool they developed possesses greater appeal than their original products. A tool's usefulness can extend beyond your initial expectations, presenting possibilities you might not have conceived of.

Final thoughts

If you really haven't any idea what could be wrong, life gets tougher!

Initiate the process by ensuring that you can prompt the bug to manifest consistently. It can be exasperating to pursue a bug that doesn't materialize with every occurrence. Invest time in crafting input data and configuring parameters that consistently trigger the issue, subsequently packaging these steps into a streamlined procedure that facilitates effortless and automated execution. Especially when dealing with a challenging bug, you'll find yourself repeatedly reproducing it as you unravel the underlying cause. Thus, streamlining the reproduction process will ultimately save you valuable time.

When confronted with a bug that doesn't exhibit consistent behavior, devote effort to comprehending the reasons behind its intermittent nature.

Forem: Rajasegar Chandran

React inside Ember - The Second Chapter

Invoking React components from your Ember apps

Rajasegar Chandran ・ Jan 31 '23

Limitations of the old approach

Advantages of the new approach

No workspace or monorepo setup required

No complex setup required

ember-react-fc

No wrapper components required

Automatic reloading

React can have Ember children

Inspiration

Vim-style repeatable key bindings for navigating windows in Emacs

Table of Contents

Vim-style repeatable key bindings for navigating windows in Emacs

Navigating windows in Emacs

windmove

repeat-mode

Key bindings

References

Exploring Syntax Trees in Emacs with Tree-sitter

Abstract Syntax Trees

Emacs

Treesitter

treesit-explore-mode

treesit-inspect-mode

Epilogue

References:

Striking a Balance: Sensibility vs Convenience in Software Development

Sensibility in Software Development:

Convenience in Software Development:

Finding the Balance:

Conclusion:

Unraveling the Chapelle Salt Trap: A Cautionary Tale in Web Development

Understanding the Chapelle Salt Trap

Possible Causes of the Chapelle Salt Trap

Mitigating the Chapelle Salt Trap

Strategic Planning

Gradual Integration of External Dependencies

Comprehensive Testing

Conclusion

Creating dynamic task runners for your npm scripts in Emacs

Prodigy

5 ways to get text from an Emacs buffer

1. Using buffer-substring

2. Using buffer-substring-no-properties

3. Using buffer-string

4. Using region

5. Using thing-at-point

Debugging rules: Change one thing at a time

Isolate the key factor

Change one test at a time

Compare it with a good one

Examine the most recent change

Ember Language Server in Emacs

Ember.js

Emacs

Ember Language Server

emacs-lsp-mode

eglot

Debugging rules: Quit thinking and look

See the failure

See the details

The Streetlight effect

Build instrumentation in

Add instrumentation on

Don't be afraid to dive in

Watch out for Heisenbugs

Guess only to focus the search

Debugging Rules: Keep an Audit Trail

Write down what you did, in what order, and what happened

The Devil is in the Details

Correlate

Audit Trails for Design are also Good for Testing

The Shortest Pencil is longer than the longest memory

Keep a notepad by your desk

Debugging Rules: Make it Fail

The Scientific Method of Debugging

3 reasons so you can

1. Using `buffer-substring`

2. Using `buffer-substring-no-properties`

3. Using `buffer-string`

5. Using `thing-at-point`