DEV Community: Vivek Kodira

Choosing an AI IDE

Vivek Kodira — Tue, 01 Jul 2025 18:02:59 +0000

NOTE: This article is cross-posted on my blog. It will be kept updated there.

Earlier this month, I had the opportunity to review several AI IDEs. I was asked to recommend an AI assistant for an engineering team. This post is a summary of my approach & findings. You probably will not learn anything earth shattering but I hope you find it useful to help clarify your own thought processes.

Criteria: Cost

I dismissed cost early on in the exercise. Most of the assistants are comparable.

Step 1 Compare AI Models

I started by comparing models across different criteria & languages using sites like https://www.prollm.ai/.

As you can see, for my chosen stack, Claude Sonnet was the winner. But the others were so close that the comparison was meaningless. For my needs, a 2 decimal difference was as good as no difference at all.

Step 2: Ask AI

Then, I asked Google Gemini make me a report. My prompt:

Come up with the criteria an AI IDE should have. Assign weights to each and then use them to compare the IDEs available today. Support for should get special mention.

Gemini produced a comprehensive report and this was more useful. It rated Cursor & Github Copilot & provided articles as reference.

The problem: many of the articles it used as reference were paid ones: marketing material from the companies themselves.

I repeated the exercise asking Gemini to ignore such sources & Cursor & Copilot still stayed on top.

Step 3: Manually verify

At about this time, I was asked to include Amazon Q in the comparison.

I decided to do a comparison for myself. For my tests, I chose Windsurf, Copilot, Cursor, TabNine & Amazon Q

My testing involved the following parameters:

Gave it a simple React component as context & asked it to run the unit test
Gave it a JSP and asked it to explain the code to me & list all the APIs the JSP invoked
The JSP had several security issues I was already aware of. I asked each AI assistant to review the code & list all security issues it could find
Finally, I asked each AI assistant how it would redesign the usecase: what APIs would it add, modify or delete.

The results have been summarised below. Copilot & Cursor were again the best of the lot. Next came Windsurf, then Amazon. I was quite disappointed with TabNine's output and dropped it at this stage.

At this point, I had two close contenders & needed to make a choice.

Step 4. Revelations

While this exercise was happening, I was also using AI for my own work & observing how members of my team used AI for their work.

This was when I had two revelations

Most developers I saw weren't using the assistants well at all.
How well an AI assistant performed at one task wasn't enough. I also need to ask: How easy was it to use as a beginner? How much friction did it cause? How easy was it to learn to use it well?

Revelation 1: Developers are the bottleneck

One example: Several developers were copying code snippets & pasting them in ChatGPT on the browser and asking it to solve the issue providing very terse & obscure instructions.

error here UserDAO is not finding session_id. What do I do?

( What should the user have done?

This kind of question needed knowledge of the codebase which an IDE-based assistant can provide better)

To its credit, ChatGPT did a great job assuming the context and provided somewhat valid suggestions

Another example: Giving the AI a too vague or too broad instruction.

Run npm run eslint. Fix all the errors you find.

Why is this a problem?

AI assistants work best when they are provided enough context & clear rules. Most times when such broad instructions were given, the AI struggled with reading the output of the command prioritising what it should do. The user would invariably find more issues than they started with or the AI would go into a loop vomitting unnecessary code at the problems

One part of the problem here are developers themselves. They'd not invested the time & efforts necessary to experiment & learn how to use AI well. This could be solved by training developers on Prompt engineering. Another part was related to the 2nd revelation - how well designed was the assistant?

Revelation 2: AI Assistant Maturity

Is the AI assistant easy to use? Does it make the user better at using it over time?

This finally was the differentiator I was looking for and was the point where Copilot fell down the rankings to 2.

Cursor, Windsurf and others like it are iterating quickly. They introduced features like memories, rules which have made us developers better at using AI for our work. Copilot is catching up but is still behind.

Here are three simple but critical examples:

Example 1: UX

This is how & what Cursor allows you to add to a chat context

Notice that you stay where you are & can add code, folders, rules, terminals and a lot more.

Now this is what Copilot does when you click on Add context in a chat:

Click on the button and you jump from the context window to somewhere else. Where you can only add code. And sometimes even after you've added a context & are conversing with the AI, it randomly forgets the context in favour of the file you've currently opened. To add instructions (copilot's equivalent of rules), you navigate to a completely different location

Example 2: Autorun

How I normally use an AI assistant these days is to help me improve the overall quality of a codebase. I experiment & iteratively improve a prompt to a point where the AI is doing exactly what I want it to do. I then ask it to go over the codebase & apply simliar changes to all the targets it finds. Then I go have a coffee. When I come back, the whole codebase is cleaned up & any workflow I've defined afterwards (ex: lint, tests) have been run.

Dedicated IDEs like Windsurg & cursor does this beautifully.

For instance, in Cursor, the user is able to setup & control every aspect of "auto-run". This feature has been present for months!

In contrast, there has been no such option yet in Copilot. It has been a pain to keep clicking "Continue" every few minutes in Copilot (Coincidentally, Copilot may have got this feature today (30th June, 2025) Github issue)

Example 3: History

Sometimes I forget my own rules of keeping AI conversations short & the AI ends up doing something I need to revert. Cursor allows me to go back in history quite easily.

Copilot does not support this feature as of today. Github Issue

There are a few more such examples and I'm sure Copilot will catch up. But as of today, IDEs like Windsurf & Cursor do a much better job than Copilot.

Conclusion

So, what AI assistant should you pay & buy an annual subscription for?

Answer: None of them. Instead, buy monthly subscriptions & experiment with any popular AI based assistant. All of them are iterating & improving. At this point, tying yourself to any one is a bad idea.

My recommendations

For now, I've chosen these tools as my current workflow:

Replit for quick prototyping
Cursor for productionising

Logseq for Task Management

Vivek Kodira — Sun, 16 Apr 2023 17:56:20 +0000

NOTE: The updated version of this article is cross-posted on my website. I'm observing some issues with dev.to where images suddenly don't appear and so will not be maintaining this article going forward.

Hello!,

I've been using Logseq for Task Management for the past several months and thought I'd write a post about the features I use and love about it.

What this post is

It is an incomplete list of features I think a good Task Management system should support with examples of how Logseq does them. Where possible, I include a few tips.

What this post is not

It is not about the benefits of personal Knowledge or Task Management .
It is not a comprehensive list of what features a Task Management System should have.
It is not an introduction to Logseq

Intended audience

This post is for people who are already sold on the merits of Knowledge & Task Management. And have tried tools like Notion, Todoist, Obsidian, Roam Research etc.

I too have tried these tools and switched to Logseq because of the following reasons:

It is open source
Its license is not restrictive and allows me to use it for Personal projects and at work
Its content is stored as markdown so my notes are not in some proprietary format that I cannot later decipher
The community around the tool is kind (and active)

How to read this post

In most cases, I've used a little text to introduce a GIF. The GIFs serve as a visual guide or example of the feature I'm demonstrating.

References/Credits

Almost everything I've learnt about Logseq has been from OneStuttering. His videos are a treasure trove of information

Features

Easy Learning Curve

A Task Management System should be easy to use. You should discover new features as you mature.

Logseq does this well. It starts with a journal view. Adding Tasks is as trivial as creating a simple list. As you learn more about the tool and task management, you'll find yourself thinking: "I wish I could do this" and discover that Logseq supports it.

Pro Tip: Start small. Don't try to build a system overnight. Doing so will make both adopting the tool harder and take you down a rabbithole of customisations you don't need.

Create and Manage Tasks

At its most basic level, a Task Management System should allow you to create and manage tasks (i.e. set statuses).

In Logseq, the blocks you add can become tasks with just a couple of key strokes CTRL+ENTER

Pro Tips:

Change the settings to switch to the workflow you prefer
Install the "Task Management Shortcuts" plugin - it allows you a few more statuses such as CANCELLED and WAITING
There are other very opinionated plugins if you want to try them. Explore the marketplace!

Prioritise Tasks

You should be able to prioritise tasks so that you can do the important stuff first.

Logseq ships with some default priorities: /A, /B or /C . Adding your own custom priorities is trivial - at the end of the day, these are just links to a page.

Schedule tasks

You should be able to schedule tasks to another day.

LogSeq allows you to do this using /schedule - you can pick the date and time when you want the task to surface and it will show up on that day in the journal

Create Repeatable Tasks

You will want to schedule some tasks to repeat every day or week.

While Logseq's scheduling capabilities are simple, they are more than sufficient for my needs.

ProTip: Use annual repeating tasks within a person's page to add birthday and anniversary reminders.

Tagging and Projects

To avoid navigating huge lists, being able to categorise tasks is important. Most task management systems support this feature but put it behind a paywall or worse, a subscription.

Since Logseq automatically creates links to pages, these can then be used to categorise tasks. So you can now categorise tasks by tagging them with project names and then put references, links etc. in the project's pages

Pro Tip 1: ALWAYS categorise tasks even if the project doesn't exist. You can always add details about the project later. Avoid generic categorisations like misc, general as much as possible.

Pro Tip 2: Add a "trigger" link to each task which will take you to the trigger for this task - could be a JIRA ticket, email or IM message. Will be useful when you are trying to trace a task back to why you did it.

Assigning Tasks

You should be able to assign tasks to others and track their progress.

Almost every system today forces you to add users to accomplish this. In my case, that is never what I actually need. When I say others, I don't mean that I want other users to see the tasks I've assigned them. Only that my dashboard should allow me to add tasks and indicate that others are working on them.

In Logseq, a person is just a block or a page like any other. So tagging a task as being done by another is trivial.

Pro tip: Write the task in plain english as #X to do Y rather than do Y #x - the first is much more readable and will make sense months down the line

Create Custom Dashboards

Most Task Management Systems are strongly opinionated.

Some Knowledge Management systems on the other hand, allow you too much customisation: so much so that you end up wasting hours on tools like Notion tweaking how it looks. Logseq's powerful query system allows you to build dashboards that will surface the content you are interested in.

The embedded gif is sometimes not working. Here is a direct link to the image

In the GIF above, I first add a /query to list all TODOs linked to my project. Then, realising a linked block is not a TODO, I go update it and verify that it shows up as well

Pro Tip 1: People are just Pages so adding the same query to a person will give you a person-specific dashboard of tasks you've delegated to someone

Pro Tip 2: I prefer a table like display for dashboards but the width available is not enough. To get rid of the spaces on either side, press t+w - this narrows the margin on either side. If this doesn't help, install a theme or play around with the custom.css file in the root folder of your Logseq graph to get the look-and-feel you want.

Copy and Move Tasks

You should be able to

Copy a task to another day
Move it to another day
Postpone to another day
Carry-over to another day

This, in my mind, is one of its most powerful features in Logseq that allows me to use it as a Task Management tool

Copy: Select the text of the task and copy it over to the target
Move: Select the text. Cut and paste it in the target
Postpone: First, create a section called "Postponed" in the journal of the day you are postponing from, now copy the reference to the task (Click on the task but don't select any text and then press CTRL+C) and paste the reference in the new day
Carry-over: The same as above but in the original day you don't move the task to the "Postponed" section

The embedded gif is sometimes not working. Here is a direct link to the image

NOTE : Anything you add under a copied reference won't show up as a linked reference in the original topic. So you may want to add explicit links

Pro Tip: 90% of the time, my tasks remain in the journal and are available in projects through Logseq's linking or my dashboards. Sometimes however, I "move" the task from the journal to the project. Doing so is again trivial. Copy the text over and add a link to the journal instead.

I typically do this when I want to breakdown/plan a large project and want a single canvas to plan in.

Breakdown Tasks

You should be able to breakdown a task. Indefinitely.

This is again where most Task Management Systems I've used in the past don't match up to Logseq. Logseq's blocks-based approach allows you to add children indefinitely.

Narrow or Broaden focus

Seeing a huge list of tasks is sometimes distracting. You should be able to narrow or broaden your focus as you wish.

Mobile Support

Task Management systems should allow you to add tasks when you think of them. This means Mobile support and the ability to sync.

ProTip: Logseq has a paid feature which allows you to sync between devices. If you'd rather not pay, you could use one of two hacks.

Add your graph to a git repository and sync using Github as source
Move your graph to Google Drive and sync using Drive's own syncing feature. For Android, I found the app "DriveSync" very easy to use and you only need to pay a one-time fee instead of a subscription for the pro version.

Features it doesn't have

Chaining Tasks

"Getting Things Done" is the book my Task Management is most inspired from. The first tool that checked almost every box was mGSD - one feature it had that Logseq does not is the ability to create a chained sequence of tasks. Tasks with dependencies which need to be accomplished first are greyed out and when the dependency is marked completed, the next task becomes active. This feature is being discussed but is not available yet

Risks

Logseq is opinionated about blocks. So there are Bullets everywhere!! - Thinking in this way can, at first, be challenging and some may never be able to do it.
Logseq stores everything in one flat folder structure. While you can create hierarchies in Logseq, the underlying files will all be at one level. This can also take some getting used to and has been highlighted by many as a concern. This decision also makes it difficult to work on the files directly outside of Logseq - like say copying all the content about a Project someplace else. If this worries you, avoid Logseq for now.

Speeding up Cypress Automation Tests

Vivek Kodira — Sat, 18 Sep 2021 15:56:36 +0000

Here are a few tips on making your Cypress automation tests runs faster.

NOTE: Some of these may seem trivial but they are all actual mistakes made by me. I hope you'll learn from my mistakes.

Write one big test rather than several small ones

A real-world integration test typically involves signon, etc before testing the actual functionality. Each test you add will therefore add to the time taken. Also, as Cypress's best practices document explains, Cypress does some housekeeping between each test. This will also slow you down if there are too many small tests.

Use `before` & `beforeEach` judiciously.

Consider this example:

    beforeEach(()=>{
        cy.login();
        cy.get('[.homePage]').should('be.visible');
    });
    //10 tests

Here, the test will login 10 times - once before each test. What I actually wanted was to login once and so should replace beforeEach with before

    before(()=>{
        cy.login();
        cy.get('[.homePage]').should('be.visible');
    });
    //10 tests

Avoid waiting for arbitrary periods of time.

Cypress explains that cy.wait(Number) is an anti-pattern and you can almost always replace it with an assertion. Read Cypress's detailed explanation and examples to understand more. If you succumb to the temptation to add cy.wait() anyway, they will eventually become a time-sink.

Tweak Cypress's configuration to remove unnecessary disk I/O

Cypress aims to "just work" and does this admirably. A configuration file is automatically created by Cypress on the first run. Some of the options here increase the disk I/O and hence slow down Cypress itself. The main culprits are:

video
videoUploadOnPasses NOTE: This one only applies if you are also using Cypress's dashboard. By default Cypress uploads all videos when connected to Dashboard which you probably don't need.
screenshotOnRunFailure

Turn these off or turn on only for nightly runs etc. where you are not worried about the time taken.

Tag tests and run only the ones you need to

Cypress's list of curated plugins includes cyress-grep. Using this plugin, you can run tests by grepping their titles or custom tags you've added to each test. Use this ability to run only the necessary smoke or feature-specific tests.

Incorporate Cypress into your CI/CD

This one is a little harder to implement but worth the effort. Take the time to read and understand how Cypress can be plugged into your CI/CD pipeline. As with everything else, Cypress's documentation here is extensive. As your test suite grows, offloading running the suite to some other system may be more performant than running all the tests locally on your laptop.

Extending a Component Library using Vuex

Vivek Kodira — Mon, 07 Dec 2020 16:27:15 +0000

At FeldsparTech we are working on a no-code platform called Atman. Atman's UI is a component library that works as a standalone application or can be embedded into another application to enable quick no-code workflows.

One of our goals is to allow granular control over our components. If this only meant rendering - we would build Renderless components. However, we also want the consuming application to be able to override, modify and augment behavior.

The approach we have chosen to achieve this goal is to use a Vuex store.

Prerequisite: Both the consuming application and the library should import and use Vuex.
We first need to dynamically register our library as a module in the application's store. This is possible through the registerModule method

if(!this.$store.hasModule("ourlibrary")){
   this.$store.registerModule("ourlibrary", store);
}

Methods that need to be customizable are implemented as actions in a vuex module. Within the action, the behavior could vary:
- If we want the consuming application to be able to override behavior, the action first checks if a global action is available and invokes it. If not, the action proceeds to perform the default logic specified in the library.
- If we want the consuming application to augment behavior, the module action first performs the internal logic and then invokes the global action (or vice versa) to perform any augmentation as necessary.

Overriding behavior example

 overriddenMethod({dispatch},params){
    if(this._actions["overriddenMethod"]) {
       return dispatch("overriddenMethod", params, {root:true});
    } else {
      //Default behavior
    }
}

Augmenting behavior example

 augmentedMethod({dispatch},params){
     let response;
     /*
        Internal logic which updates `response`
        ...
     */
    if(this._actions["augmentedMethod"]) {
       globalResponse = dispatch("augmentedMethod", params, {root:true});
    }
    /*
        Update `response` with `globalResponse`
    */
    return response;
}

This pattern is quite powerful. For instance, you can now even allow the consuming application to entirely replace a particular nested component with one of its own.

Here, the vuex action functions as a Factory. Now you can customize the logic as per your needs. The Overriding approach will entirely replace default component. The Augmentation approach will allow the consuming application to add business-specific components you may not want in the library.

Dynamic Component in the Library

<template>
    <component v-if="currentComponent" v-bind:is="currentComponent"></component>
</template>
<script>
export {
    //...
    async mounted() {
      this.currentComponent = await this.$store.dispatch(`<module>/deriveComponent`)
    }
}
</script>

Action in Library's store

deriveComponent(context, params) {
    let currentComponent;
    //augment or override as per your requirements
    return currentComponent

}

Resources I found useful during this exercise

Github template to create a vuetify component library
mitevpi / vuetify-component-lib-template

Template for creating a component library/design system using Vue.js and Vuetify.js.
Vue.js + Vuetify.js Component Library Template

A Design System / Component Library Template for enabling graphic consistency and legibility across web development projects by creating reusable components and styles with accessible & legible documentation Built on top of Vue.js and Vuetify.js.

Usage

This Template is comprised of two major categories: Styles and Components. It builds to compiled components (.js) and compiled styles (.css) from the source (.vue) files which can be used across web applications. It also creates a Storybook site for component/design system documentation.

Clone this repository locally, and use it as a starting point for building a component library / design system on top of Vue.js and Vuetify.js

Added/Updated Configurations to Vue CLI Starter
Key Commands

After cloning/downloading the repository locally, install the required dependencies using…
View on GitHub
A step-by-step series by siegerts on how to create a Vue JS component library

Creating a Vue.js component library: Part I - Introduction

siegerts ・ Jul 7 '20

#vue #library #plugin #vuepress

Also cross-posted on Medium

Online Reading — Why it fails for some formats

Vivek Kodira — Sat, 21 Nov 2020 14:05:04 +0000

Did you know that the world does not know whom to credit as the inventor of E-books? There are contenders for the title from as far back as 1946. Ref

For you and me, our first time experiencing e-books were as PDF documents. These were typically technical journals and pirated scanned versions of popular books.

It took some time for traditional publishers to accept this new format and begin selling them but since then e-books have exploded. Project Gutenberg now has over 60000 books one can read for free. For many of us, E-books are now the preferred format. This could be for several reasons:

Cost (an e-book is typically cheaper than the physical alternative)
Space (e-books don’t take up any space. You can carry a thousand on a holiday)
Convenience (you can read an e-book in the dark)
Environmental impact (e-books don’t need paper and so fewer )

But even the most ardent fans of the format will admit that there are disadvantages.

With e-books we lose the tactile experience of touching and feeling a physical book
Some formats, graphic novels, comics and childrens’ books for instance do not lend themselves to an e-book format The second disadvantage is the focus of this blog.

Graphic Novels and Comics as Ebooks

With the limited screen real estate in small devices, text such as speech bubbles in graphic novels and comics are often not seen clearly. Google and Amazon, the big two players in the e-book market both address this in similar ways — by zooming in certain portions of the page.

Google’s Bubble Zoom enhances speech bubbles in each panel. Amazon’s Guided View navigates a comic panel-by-panel

These approaches address one problem but end up creating another. Arbitrarily zooming in on certain portions and truncating others may make the text legible but harm the overall experience.

The focus on the textual content mean that user loses out on experiencing the art.

How do you do justice to art?

Graphic Novels, comics and Childrens’ books are as much about the illustrations and the art as the story.

The art in such books are a labour of love and painstakingly detailed. Mobile Form factors do not render these as originally intended by the artist.

Artists and authors recognize the issue and are beginning to address this problem in new ways. Webtoons, a site with mostly South Korean artists, formats all content in vertical panels with very large text bubbles — this is art designed specifically for consumption on mobile devices.

Graphics are not just for entertainment

Before we dismiss this problem as trivial and relevant only to entertainment, consider that graphics are an integral portion of most technical manuals. To quote a cliche “a picture is worth a thousand words”.

Today, graphical novels are being used for more than just comics. Google has used them to explain the inner workings of a browser. Universities use them to explain copyright laws. So this isn’t a challenge to be taken lightly.

Where do we go from here?

Content creators are evolving to produce art that is more easily rendered on mobile devices. E-book stores are creating technology to help improve a consumer’s experience of consuming such content. However, convenience and market forces are not the only driving factors. As technology makes them more affordable, people who can afford it, are moving to other larger form factors such as tablets. These solve the problem of real estate.

At FeldsparTech, one of our design tenets is to model technology after nature and the real world. We believe that reading a digital book should be as similar to reading a physical one as we can make it. And that everything else that consuming digital media typically entails (algorithms, annoying ads) should be removed or reduced from the user’s experience.

References

Also posted here

Sunk Cost Fallacy and Books

Vivek Kodira — Sat, 21 Nov 2020 13:50:51 +0000

“Individuals commit the sunk cost fallacy when they continue a behavior or endeavor as a result of previously invested resources (time, money or effort)
(Arkes & Blumer, 1985)”

How often have you read a terrible book all the way through just because you have already paid for it or read halfway through it. This is the sunk cost fallacy at play.

Online book stores allow you to preview books — read the first few pages before deciding. But what if you decide you don’t like a book halfway through?

There are two factors that typically contribute to the sunk cost fallacy — one is the effort and time already invested, the second is the actual money already spent.

There is not much one can do about the former, but the financial cost is definitely something that can be addressed. There are two ways to do this.

The easiest is to reduce the cost so that you the consumer don’t have to worry about it when deciding what to do next. This approach however is zero-sum — i.e to benefit you, the creator of the content you are consuming will have to suffer.
Another is a pay-per-use model. You pay only for what you consume. When you decide to stop, you can. But not all media lends itself to this model; books for instance. But what if there was a way to implement pay-per-use for books?

We at FeldsparTech think we know of a way and can’t wait to show you what we have in mind.

Also posted here

How we Converted our Products into a Platform

Vivek Kodira — Mon, 09 Mar 2020 18:02:03 +0000

Organisations which design systems […] are constrained to produce designs which are copies of the communication structures of these organisations.
— M. Conway

JFrog’s products cover a broad range of DevOps processes: from Artifactory which helps development teams manage binaries, to Mission Control which helps manage Artifactory instances, Xray which helps avoid security vulnerabilities and Distribution which helps distribute binaries in a large organisation.

Over time, Conway’s law has applied to our products. Despite our best efforts, our products had begun to diverge in their user experience, architecture, interfaces and design choices.

A chief goal of the JFrog Platform was to fix this divergence and provide a unified experience to our users. A platform comes with several benefits - this blog would be twice as long if I listed them all. Instead, you can read more about them here.

Instead, I will focus on answering the question: How do you go about converting several products into a single platform?

This was a mammoth exercise involving every team in JFrog. This blog will explain how we in JFrog RnD broke down the task.

When we considered what areas end-users interact with most in our products, the following stood out.

User Experience
Installation
Configuration
Logging
APIs

User Experience

We’ve always had a common base library of components and styles which every UI team consumed, but now we went all the way and created a single pane of glass for all our products: A Unified UI.

To create a unified UI, we restructured our codebases.

Every product’s UI code was extracted and merged into a single one. A thin backend layer was introduced to ensure requests were still routed to the original product. Developers still remained part of product teams: ensuring deeper domain knowledge and expertise.
Pull Requests would now be available to be reviewed by the entire Front End Developers (FEDs) team. This process initially introduced some delays but made up for it by improving our quality and standardisation.
Common modules (such as global search, permissions, users, groups, roles, etc.) were dropped from individual products and rewritten to be generic across products.

Installers

Our products can be installed on several different Operating Systems. Some, like Artifactory, appear monolithic and others create several microservices. Artifactory, can be configured to work with PostgreSQL, Oracle, MySQL, MS SQL or MariaDB while others need explicit databases to function (ex: Mission Control needs Elasticsearch, Xray: RabbitMQ, Distribution: Redis).

Moreover, not all users would want every product pre-bundled in the platform. They would want to be able to choose exactly what they install. This necessitated an installation process that allowed all the products to work together seamlessly while still being discrete entities.

A dedicated team was created to develop and maintain installers.
This team collected feedback from Support engineers, Architects and product RnD groups. Its goals were to standardise the user experience of our installers while maintaining backward compatibility.
A single repository was created for shared code and routines.
This allowed the team to abstract common logic and put them in a single location
This repository is referenced in each product’s build to create the final installer. This allowed product-level customisation of the installation process where necessary.

An important outcome of this restructuring is that all our installers feel similar. For instance, every product installation variant now also contains an interactive wrapper script which asks similar questions. Another is that all our products are now installed with a standard folder structure. You can read more about this structure in Eldad’s blog

Configuration

Our products are written in several different programming languages. Java is the most common, but Go is fast becoming popular. This has meant that how we read configuration is also very different between products. Some read property files, others: XML, etc.

For the unified platform, we decided to standardise this to a single configuration file: the system.yaml.

To implement this, we needed process and code changes.

We developed a common configuration manager library in every language we needed it in: bash, go, node, java. We did briefly consider creating a shared “configuration microservice” but dismissed it - since reading configuration is such a basic task which shouldn’t need API calls.
We then mandated that every microservice should read configuration using only this library.

Logging

Unifying Logging was critical. Doing so ensured a consistent troubleshooting experience, easier support, better automation and easier integration with third-party log aggregators.

JFrog’s software architects came up with a proposed structure. Each team only had to change the configuration of the logger library. Or in case of languages like bash, which do not support Log4j, implement the new structure.

One of the outcomes of this exercise is that all our logs now follow a standard structure. The platform also produces a new console.log which aggregates logs from all our products’ microservices and shell scripts into a single file.

APIs

We needed to implement a consistent, and futuristic approach for APIs while also ensuring backward compatibility. We did this by retaining our individual product APIs, but adding a layer around them which would allow incremental standardisation.

If you inspect the microservices which each product now starts up, you’ll notice that one is repeated in every product: a router.

The router forms the backbone of all api-based communication between microservices within a product, between products, and between a product and the outside world. It takes care of network-level details, allowing product developers to focus solely on business logic.

To implement this, we formed a dedicated team whose mandate was to manage, standardise, and optimise communication.
Artefacts produced by this team are bundled in every product’s build and used as microservices.

Conclusion

Converting our products to the unified platform required a combination of organisational restructuring, architectural, design & process changes. This last year, our teams have evolved along with the product itself. The experience has been an enriching one, and one we hope will show in the product we are proud to have created.

Lessons Learned Building JFrog Platform Installers: Applying the Template pattern to Shell Scripts

Vivek Kodira — Tue, 25 Feb 2020 16:27:45 +0000

Artifactory, JFrog’s flagship product, has been in the market for more than a decade now. Individual developers working on Open source projects, Startups - big and small, and large Enterprises all use it to store binaries. Over time, Artifactory has shipped with every installation type imaginable: from ZIP files, to native installers & Helm charts.

Over the years - to further our vision of Liquid software, we’ve launched other products: Xray, Mission Control & Distribution in this ecosystem.

As each product matured, their installers began to rely on interactive installation scripts.

Interactive installation scripts offer an easier experience to an end user. To product teams, they are attractive because they:

Offer finer grained control over the installation experience
Reduce need for elaborate documentation covering all possibilities
Make user errors less likely

Last year, at SwampUp 2019, we announced the new JFrog Unified Platform. Our aim was to provide a unified experience to all users of our products. One of these experiences was the installation of our products.

From an installation perspective, our goals for the installation experience were that each be:

Backward compatible
Easy to use
Unified (Similar, work well with each other)

With these in mind, all our products now ship with interactive installation scripts. The one notable exception is the native installation package for Artifactory - which, we felt was simple to install.

The experience of building installers for JFrog products was challenging and enriching for my team and me. We learned much during the process about customer focus, enhancing support-ability, design and user experience.

The rest of this blog deals with one specific set of lessons: those learned from applying the Template pattern to shell scripts.

Template Pattern

At a very high level, what an interactive installation script does is very simple and is demonstrated in the diagram below.

Things get complicated when we get into details.

Each product has its own microservices. (Read more about our System Architecture here)
Each uses different databases. For instance, Xray uses RabbitMQ for messaging, Distribution uses Redis and Mission Control: ElasticSearch. (Read more about the Databases we use and support in Common Resources)

The problem statement then is

“We have a common sequence of operations but each step in the operation is implemented differently“

This, we realised, was simply the Template pattern.

Template method is one of the behavioral design patterns identified by Gamma et al in the book Design Patterns.

The template method is a method in a superclass, usually an abstract superclass, and defines the skeleton of an operation in terms of a number of high-level steps. These steps are themselves implemented by additional helper methods in the same class as the template method.

The intent of the template method is to define the overall structure of the operation, while allowing subclasses to refine, or redefine, certain steps

Most programming languages, such as Java, have support for class hierarchies and abstract methods which make implementing the template pattern straightforward. Bash, the language we wrote our interactive scripts in, does not have the same language constructs. Therefore we had to improvise. However, it turned out to be fairly simple.

Template Pattern - Approach 1

One approach was to simply encapsulate the sequence within a generic script with a main method. The user would invoke the generic script. The script in turn, would invoke the product-specific hooks.

Notice that in this approach

Each hook needs to be explicitly coded for. The product-specific script cannot decide what methods it wants to override.
Each hook has to be implemented (even if with a dummy implementation) in the product-specific script. Not doing so will result in a runtime error.
Variables available to the parent script, unless they are also exported as environment variables, are NOT available to the product-specific script and vice-versa.

This approach is particularly suited (and even recommended) for scenarios where you are invoking a third-party script - one whose internals you don’t care about and with which you don’t want to share too much of your internal state, etc.

Template Pattern - Approach 2

Consider an alternative approach, depicted by the sequence diagram below:

Here, the user invokes the product-specific script. This allows us to bootstrap with product-specific variables before beginning the common sequence of operations
The product-specific script sources the generic script and invokes its main method. This allows variables to be shared across both scripts.
Sourcing also facilitates method overriding. Methods in the product-specific script, which appear below the sourced script’s methods, override the ones in the generic script.
This approach also avoids unnecessary code duplication. The generic script already contains dummy or actual method implementations. Only hooks which need to be implemented in the product-specific script need to be added to it.

This approach is more suitable when you own both scripts and want them to share information.

Conclusion

Implementing the template pattern allowed us to control the overall installation experience while being able to accommodate every product’s particular quirks. It made our design more agile and even allowed us to easily incorporate changes later in the development cycle, from our beta users.

Do let me know in the comments if you found this blog’s contents useful and would like to know more about the other lessons we learned.

References

Template Pattern
The Flow chart was created using https://www.draw.io/
The Sequence diagrams were created using https://www.websequencediagrams.com/

This article is also posted on medium

Automate a multi-window experience on iTerm2

Vivek Kodira — Sun, 18 Aug 2019 05:11:05 +0000

TLDR

This post is a tutorial. The final outcome will be a script that creates several sessions on a remote machine, running commands in parallel. Jump to the end to see the final script or read on for a step-by-step tutorial

Why would you want iTerm automation?

Here is an example from my own workflow:

The installation script I'm testing these days launches several containers, creates folders with different user permissions and copies files back and forth between mounted folders.

These are the steps I need to do each time I begin testing

Create 4 sessions in an iTerm tab
ssh into the remote machine I'm testing*
switch to sudo*
Install the software I will need (docker, docker-compose, etc.)
Configure watch to monitor docker containers in one session
Configure tree to watch the folder structure in another
Configure watch with cat to monitor some files in the third
And run the installation script in the last container

*Repeated in each session!

You can see how doing this over and over becomes tedious. Shell scripts would be able to automate some steps above but not enough.

AppleScript to the rescue!

Hello world!

Let's start with a hello world.

Create a file hello_world.scpt with the contents below:

#!/usr/bin/osascript
tell application "iTerm2"
    set contentToPrint to "hello world"
end tell
do shell script "echo " & contentToPrint

Run this script (osascript hello_world.scpt). You should see hello world in the terminal

The code above is reasonably self-explanatory, so let's jump right into the next example.

Hello world .. again?

Create a file hello_world2.scpt with the contents below:

#!/usr/bin/osascript
tell application "iTerm2"
    tell current session of current tab of current window
        write text "echo 'hello world again!'"
    end tell
end tell

Run this script (osascript hello_world2.scpt). You should see

~ osascript hello_world2.scpt
echo 'hello world again!'
~ echo 'hello world again!'
hello world again!

Though the final output is similar, this version printed a few more lines as well. How is this different from the earlier script?

Press the 'up arrow' to see the last command in the terminal's history. It'll display

echo 'hello world again'.

Press up again and this time you'll see

osascript hello_world2.scpt.

The difference then is this: hello_world2.scpt executed the instruction we gave it on the terminal. The echo got added to the terminal history.

Personally, I prefer this second approach - it is both more readable and I want to be able to search for and execute these individual commands if I need to.

Creating multiple sessions

Let's now automate creation of multiple sessions

Create a file sessions.scpt with the content below

#!/usr/bin/osascript
tell application "iTerm2"
    tell current session of current tab of current window
        split horizontally with default profile
    end tell
end tell

Run it and you'll see that it will divide the terminal into two horizontal sessions

Similarly, running a script with the content below will divide the terminal into two vertical sessions.

#!/usr/bin/osascript
tell application "iTerm2"
    tell current session of current tab of current window
        split vertically with default profile
    end tell
end tell

Sessionception!

You can issue commands to each session. Let's create two vertical sessions within each horizontal session.

Create a file sessionsception.scpt with the content below

#!/usr/bin/osascript
tell application "iTerm2"
    tell current session of current tab of current window
        split horizontally with default profile
        split vertically with default profile
    end tell
    tell third session of current tab of current window
        split vertically with default profile
    end tell
end tell

The part that might be confusing is figuring out which is the second, third and fourth sessions. Just remember that sessions are not numbered in the order they are created. Session numbering is left-to-right on the first row and then similarly on subsequent rows.

This is why even though the horizontal session was created second, when addressing it in the script, the command is tell third session

Back to the future

Let's jump ahead to the final script I need. Here it is below

#!/usr/bin/osascript
tell application "iTerm2"
    tell current session of current tab of current window
        write text "setupTargetMc"
        write text "sshmc2"
        write text "sudo su"
        write text "./installStuff.sh"
        write text "watch -n1 'docker ps --format=\"{{.Names}} {{.Ports}} {{.Status}}\"'"
        split horizontally with default profile
        split vertically with default profile
    end tell
    tell second session of current tab of current window
        write text "sshmc2"
        write text "sudo su"
        write text "watch -n1 'tree -u -d  ~/.temp -L 3'"
        split vertically with default profile
    end tell
    tell third session of current tab of current window
        write text "sshmc2"
        write text "sudo su"
        write text "watch -n1 'cat ~/.temp/key'"
    end tell
    tell fourth session of current tab of current window
        write text "sshmc2"
        write text "sudo su"
        write text "clear"
    end tell
end tell

Much of the content above should be simple to understand by now. But here, if you need it, is a breakdown of some lines which may be unfamiliar

write text "setupTargetMc" - invokes setupTargetMc - an alias I've created beforehand to copy scripts I need (installStuff.sh) to the target machine
write text "sshmc2" - invokes sshmc2 - an alias I've created beforehand to ssh into the target machine
write text "./installStuff.sh" - triggers ./installStuff.sh. This is the script we copied over in the first step. It will setup the machine to my requirements including installations of all the software I need
watch is used in several sessions, together with other commands, to continuously monitor docker containers, folder structures and contents of files

Conclusion

iTerm automation has saved me a lot of time and effort. Hopefully, this post will motivate you to try it and give you the means to write your own. Best of luck!

References

Using Badges in iTerm2

Vivek Kodira — Sat, 06 Jul 2019 15:50:29 +0000

Update: 1-Aug-2019: The example mentioned in this post is now redundant. Use iTerm's status bar instead.

iTerm2 is a very powerful replacement to the built-in terminal. You can read more about why here.

This post will focus on one specific functionality I recently explored and found useful: Badges and is meant for beginners unfamiliar with iTerm2

Hello World

Let's start with a "Hello World" example.

Go to "iTerm2 > Preferences > Profiles"
Add the text "HelloWorld" to the input "General -> Basics -> Badge"

If you open up a new iTerm2 window, you should now see this:

This badge will be displayed in each tab. Split the window into two tabs and this is what you'll see.
Now lets make the badge display something useful like the name of the user and the machine. To do this, we'll first need to install Shell Integration
Now, go back to the Preferences panel and change the Badge to \(session.username)@\(session.hostname)
iTerm will now display a more useful badge

Important: The "Install Shell Integration" step will have to be done on each host you ssh into before you'll see the correct label.

Enjoy,
Vivek.

P.S: Badges also support more advanced features like user-defined variables. Experiment with them to get the look-and-feel you need. All you need to know is some basic bash scripting

DEV Community: Vivek Kodira

Choosing an AI IDE

Criteria: Cost

Step 1 Compare AI Models

Step 2: Ask AI

Step 3: Manually verify

Step 4. Revelations

Revelation 1: Developers are the bottleneck

Revelation 2: AI Assistant Maturity

Example 1: UX

Example 2: Autorun

Example 3: History

Conclusion

My recommendations

Logseq for Task Management

What this post is

What this post is not

Intended audience

How to read this post

References/Credits

Features

Easy Learning Curve

Create and Manage Tasks

Prioritise Tasks

Schedule tasks

Create Repeatable Tasks

Tagging and Projects

Assigning Tasks

Create Custom Dashboards

Copy and Move Tasks

Breakdown Tasks

Narrow or Broaden focus

Mobile Support

Features it doesn't have

Chaining Tasks

Risks

Speeding up Cypress Automation Tests

Write one big test rather than several small ones

Use before & beforeEach judiciously.

Avoid waiting for arbitrary periods of time.

Tweak Cypress's configuration to remove unnecessary disk I/O

Tag tests and run only the ones you need to

Incorporate Cypress into your CI/CD

Extending a Component Library using Vuex

Overriding behavior example

Augmenting behavior example

Dynamic Component in the Library

Action in Library's store

Resources I found useful during this exercise

mitevpi / vuetify-component-lib-template

Template for creating a component library/design system using Vue.js and Vuetify.js.

Vue.js + Vuetify.js Component Library Template

Usage

Added/Updated Configurations to Vue CLI Starter

Key Commands

Creating a Vue.js component library: Part I - Introduction

siegerts ・ Jul 7 '20

Online Reading — Why it fails for some formats

Graphic Novels and Comics as Ebooks

How do you do justice to art?

Graphics are not just for entertainment

Where do we go from here?

References

Sunk Cost Fallacy and Books

How we Converted our Products into a Platform

User Experience

Installers

Configuration

Logging

APIs

Conclusion

Lessons Learned Building JFrog Platform Installers: Applying the Template pattern to Shell Scripts

Template Pattern

Template Pattern - Approach 1

Template Pattern - Approach 2

Conclusion

Automate a multi-window experience on iTerm2

TLDR

Why would you want iTerm automation?

Hello world!

Use `before` & `beforeEach` judiciously.