DEV Community: Dmytro Zaichenko

Should I Learn RoR in 2021?

Dmytro Zaichenko — Fri, 18 Dec 2020 09:32:42 +0000

To know more about RoR, check a detailed guide Everything You Need to Know about Ruby on Rails Web Application Framework

A short answer: YES
A little bit developed answer: Yes, you should try at least.

It can be tough to make up your mind about the next framework to learn with so many available options. Depending on your interests, RoR may be one of the best on the list. Why? Let’s see.

Community

There’s a vibrant community around it, and over 4.2k contributors to the RoR GitHub page (the hugely popular Django, Laravel, or ReactJS don’t even have half of that). The RoR community is active and known for being very open and helpful to newcomers.

Easiness

It’s relatively easy to learn, especially if you already know JavaScript or a similar framework. The language is expressive, and the syntax is clean and easy to comprehend.

Quickness

It’s quick to work with, and with the abundance of resources, you can deliver things in no time. Incredibly helpful if you’re planning to work on your own prototypes or pet projects.

Product-oriented approach

Working with RoR inevitably means working closely with products. RoR teams are often found in startups, and they’re small and focused. Engineers are often exposed to customer insights and gain a deeper understanding of the product. This can be an invaluable experience if product management is your field of interest.

Paycheck

Coding in Ruby also pays well. According to the 2020 Stack Overflow Developer Survey, Ruby was among the frameworks guaranteeing the highest paycheck.

Logic

Rails does many things with logical conventions, so you can focus on the core of your application. The code is clean and easy to understand and maintain. “It’s just fun to use” was a widespread response when we asked our devs why they love coding in Rails.

When not to choose RoR?

When should you opt for one of the Ruby alternatives instead of choosing RoR? Whichever way you go, you’ll need to have a general understanding of JavaScript along with HTML/CSS to become a successful web developer. For this reason, if you’re just getting started, picking up JS may be the right approach.

If Rails appealed to you with its MVC architecture but something else didn’t quite match, ReactJS could be a viable alternative. It’s trendy, quickly growing, and is undoubtedly in demand. The same can be said about Laravel, which has grown a fantastic community around it and provides tons of resources for those just getting started.

If you always want to be on top of the latest technology trends, you can’t overlook Python and its most popular framework, Django. It offers a rich ecosystem and an abundance of features that simplify development. Many of them came from Rails and enhanced it, quickly becoming some of the all-time favorites.

Among other popular options, Java-based Spring and a JS family of Angular, Vue.js, and Express should certainly not be overlooked.

This post was originally published by my colleague Piotr Malek on Railsware blog

Angular end-to-end testing tips

Dmytro Zaichenko — Thu, 26 Nov 2020 14:52:49 +0000

We all love to write end-to-end specs, don’t we? The reason is that these scenarios act as watchdogs, making refactoring safer and sometimes being the one and only feature documentation existing in the codebase.

The only downside is that sometimes it takes ages to have a proper data setup, resolve CSS classes dependencies and constant CSS/HTML changes. Readability and maintainability are not always perfect too. Well, we have a few simple techniques that can help you overcome most of the issues described above. Written for end-to-end Protractor specs, they can be easily used with a testing framework you prefer.

Let’s check a simple example of markup

...

    I'm an awesome label

...

with related specs

describe('Awesome page', () => {
  beforeAll(() => {
    browser.driver.get("http://mysite.com/awesome");
  });

  describe('Awesome block', () => {
    const block = element(by.css('.awesome-block'));
    const label = block.element(by.css('.utility-class'));

    it('has awesome label', () => {
      expect(label.getText()).toEqual("I'm an awesome label");
    });
  });
});

and try to improve them.

Separate test specific attributes

If you have engineers working separately with CSS/HTML and Angular/JS components then you have probably faced an issue that markup changes are not safe in terms of spec dependencies.

Front-end engineer can accidentally break specs by just changing the utility-class name or applying different class according to CSS changes. Although this issue can be avoided by checking end-to-end specs selectors whenever a markup change is applied, that’s not very convenient. An alternative solution would be having proper stable semantic classes on every tested element, but that’s just too ideal 😉

The other option is to have a special attribute that is used ONLY by testing framework:

I'm an awesome label

It looks like we are having obsolete attributes all around our markup. Although using this technique we have obtained a number of benefits:

Every tested element has a separate meaningful name
Markup changes are much easier and "safer"
Specs do not dependent on CSS changes

Page/Component objects

When writing end-to-end tests, a common pattern is to use page objects. It makes easier to maintain and reuse spec examples. Let’s define simple page objects for our specs:

class PageObject {
  constructor(public finder: ElementFinder) {  }

  protected get element() {
    return this.finder.element.bind(this.finder);
  }

  protected getChild(locator: string) {
    return this.element(by.css(locator));
  }
}

class AwesomeBlock extends PageObject {
  get awesomeLabel() {
    return this.getChild('[data-test=awesome-label]');
  }
}

class AwesomePage extends PageObject {
  visit() {
    browser.driver.get("http://mysite.com/awesome"); 
  }

  get awesomeBlock() {
    return new AwesomeBlock(this.getChild('[data-test=awesome-block]'));
  }
}

Test examples will now look like this:

const page = new AwesomePage(element(by.css("body")));

describe('Awesome page', () => {
  beforeAll(() => {
    page.visit();
  });

  describe('Awesome block', () => {
    const awesomeBlock = page.awesomeBlock;

    it('has awesome label', () => {
      expect(awesomeBlock.awesomeLabel.getText()).toEqual("I'm an awesome label");
    });
  });
});

Much cleaner, no CSS selectors in examples but can we improve this even more? Sure! With a common test-specific attribute on every testable element and TypeScript decorators page objects can look a bit fancier:

class AwesomeBlock extends PageObject {
  @hasOne awesomeLabel;
}

class AwesomePage extends PageObject {
  visit() {
    browser.driver.get("http://mysite.com/awesome"); 
  }

  @hasOne awesomeBlock: AwesomeBlock;

with decorator defined as:

export const hasOne = (target: any, propertyKey: string) => {
  Object.defineProperty(target, propertyKey, {
    enumerable: true,
    configurable: true,
    get: function () {
      const child = this.getChild(`[data-test=${_.kebabCase(propertyKey)}]`);
      const PropertyClass = Reflect.getOwnMetadata("design:type", target, propertyKey);
      return new PropertyClass(child);
    },
  });
};

Now we have reusable spec examples that are not dependent on CSS changes and a nice DSL to define Page/Component classes.

The insights and code samples were made by Railsware engineering team

How to Manage Acceptance Criteria in Jira

Dmytro Zaichenko — Tue, 13 Oct 2020 07:23:32 +0000

This post was originally published on Smart Checklist for Jira blog

The success of a project depends on communication between the dev team and the customer or the stakeholder. The team needs to know how the product or feature is expected to work – this is specifically what the Acceptance Criteria in User Stories in Jira explains.

The more detailed description the customer is able to provide about their business needs, the fewer questions the team will ask after work starts. Yes, the team needs to understand all requirements clearly – no question about that. Without this seemingly obvious aspect, things can become rather challenging.

Let’s take the following case:

The client (owner of a clothing store) wants to add a Search to their homepage so that users can search for clothes categories. They want a clear interface with filters that show all categories in the form of a dropdown. Two weeks fly by and instead of super-fast filters that show all categories, the client gets a Search where users need to type in everything manually. This also works, but the user experience will suffer.

What is the Acceptance Criteria?

As stated above, when a feature is built by a dev team, it must meet a certain set of rules to satisfy the user and the customer. This set is what we call Acceptance Criteria. Ultimately, the goal of the Acceptance Criteria is to ensure that the team knows what to build before work starts. Additionally, Acceptance Criteria helps to verify automated tests of the User Story. A typical example of Acceptance Criteria in a User Story list would be:

User story: As a user, I want to sign up for a marketing newsletter to receive emails about the latest offers.

Acceptance criteria:

The user can sign up for a newsletter in a few places: the homepage footer, the slide-in pop-up, and a modal on the product page when shopping.
The user can only sign up with a valid email.
There should be an Email Input on both, the slide-in pop-up and modal so that users can leave their email addresses.
After the user leaves their email, they will get a confirmation email

So to put it simply, a user will not accept the functionality if they can’t leave their email to sign up for a newsletter. They wouldn’t know if they signed up correctly without a confirmation email sent to them afterward.

Acceptance Criteria vs. Definition of Done

As long as the Definition of Done and Acceptance Criteria are both present in the scrum development process, they should not be confused. They are not interchangeable. An example of a Definition of Done would be:

Code checked
Code review passed
Functional tests passed
Product Owner acceptance

So what are the differences?

The main difference between the two is that the Definition of Done applies to all User Stories in the backlog, while Acceptance Criteria is unique for individual Stories. While Acceptance Criteria explains how things will work, the Definition of Done is a list of items that have to be “checked” by the team before shipping a product, a release, or even the slightest feature.

Also, the two serve a different purpose. The goal of DoD is to ensure the highest quality of the product, whereas the Acceptance Criteria serves as a guide for the team to let them know how the user will interact with the product as well as when the Story is eventually completed.

How to manage Acceptance Criteria with Smart Checklist

If you’re wondering where to add Acceptance Criteria in Jira, we’ve got you covered. There are a few ways to do this. Some prefer to include it in the Description text area as a simple list, which isn’t the most perfect solution. Smart Checklist for Jira makes it so easy to manage Acceptance Criteria in Jira, without the need to squeeze it inside the task’s description.

All it takes is just a few clicks to download and install Smart Checklist. You will then see the tab to the right side of each of your existing User Stories and every next Story that you create.

Adding Acceptance Criteria in Jira

Once installed, Click Open Smart Checklist to start adding the Acceptance Criteria list for the Story.

The great thing is that Smart Checklist gives you a little bit of flexibility – you can add items to the list one by one or open the Fullscreen Editor to edit the entire list at once. Click the Pen icon to open the Editor.

Now, you can use this Formatting Guide to perfectly style your list, as it supports Markdown features where:

Means “To Do”
Means “Done”

[~] Means “In Progress”
[x] Means “Cancelled”
[#] Is the List Header

Once you’re done, hit Save. The entire list will appear to the right side of the User Story. The list will appear at the center, under the User Story’s description by default. You can move it to the right if you prefer at any time.

Key Takeaways

At the end of the day, all the reasons behind adding Acceptance Criteria to your User Stories are unbeatable. That is because a well-written, clear acceptance criteria list saves you and your team from some unexpected issues on the day of release (or after it). On top of it all, it guarantees that everyone, stakeholders, clients, devs, and the users are happy with how the product works.