DEV Community: Nesha Zoric

React JSX - How to do it the right way - Part II

Nesha Zoric — Mon, 04 May 2020 07:54:59 +0000

In the previous part of React JSX series, we took a look at how to correctly loop through arrays and objects in React. In this article, we'll help you learn how to write conditional statements when rendering components.

Everything below applies to React Native as well!

Conditional statements inside React render

While learning to code in React, most of us have probably tried this and realized it won't work:

render() {
    return (
        <div>
            {
                // this won't work
            }
            {
                if (condition) {
                    // do something
                } else {
                    // do something else
                }
            }
        </div>
    )
}

JSX is just a syntactic sugar for function calls and object construction, and, although JavaScript is pretty flexible, we still can't pass the code like the if-else above as a parameter to a function.

Below are the correct ways to do the conditioning!

Let's say we have a flight object and in our Flight component, we want to show whether it's cancelled or not. The most usual way to do simple conditioning like this is via ternary expressions:

render() {
    return (
        <p>
            {
                flight.cancelled ?
                    'Cancelled'
                    :
                    'Regular'
            }
        </p>
    )
}

Ternary expressions are okay for simpler stuff but what happens if we have something more complex?

Let's say, what if we have a situation where we should use an else if statement?

Of course, we can do something like this:

render() {
    return (
        <p>
            {
                flight.cancelled ?
                    'Cancelled'
                    :
                    ( 
                       flight.arrived ?
                           'Arrived'
                           :
                           'Regular'
                    )
            }
        </p>
    )
}

This can easily pile up and start looking pretty messy and unreadable. What's the better way then? Do the conditioning above the return statement:

render() {
    let status;
    if (flight.cancelled) {
        status = 'Cancelled';
    } else if (flight.arrived) {
        status = 'Arrived';
    } else {
        status = 'Regular';
    }
    return (
        <p>
            { status }
        </p>
    )
}

Now, in previous examples, we were only rendering a status in our component, but usually, there will be much more to render. So, if we want to render the departure time, the destination, the arrival time and status, for example, it might look something like this:

render() {
    let status;
    if (flight.cancelled) {
        status = 'Cancelled';
    } else if (flight.arrived) {
        status = 'Arrived';
    } else {
        status = 'Regular';
    }
    return (
        <div>
            <p>
                Destination: { flight.destination }
            </p>
            <p>
                Departure time: { flight.departureTime }
            </p>
            <p>
                Arrival time: { flight.arrivalTime }
            </p>
            <p>
                Flight status: { status }
            </p>
        </div>
    )
}

Now, this is okay, it's working, but we're polluting the render method of a component. Imagine we had more if-else statements - it'd be a mess.
Instead, why wouldn't we move it outside of a render method, so it's completely separate?


renderStatus() {
    let status;
    if (flight.cancelled) {
        status = 'Cancelled';
    } else if (flight.arrived) {
        status = 'Arrived';
    } else {
        status = 'Regular';
    }
    return status;
}

render() {
    return (
        <div>
            <p>
                Destination: { flight.destination }
            </p>
            <p>
                Departure time: { flight.departureTime }
            </p>
            <p>
                Arrival time: { flight.arrivalTime }
            </p>
            <p>
                Flight status: { this.renderStatus() }
            </p>
        </div>
    )
}

Our code looks way neater now, right?

All of the examples above were about rendering a simple string based on some boolean values but what could have happened if we had to add a different class, or pass a different prop? Logic is the same.

Let's say we have a button to book a flight unless it's cancelled:

renderButton() {
    let handleOnPress;
    let buttonClassName;
    let buttonText;
    if (flight.cancelled) {
        buttonClassName = 'button disabled';
        buttonText = 'Cancelled';
    } else {
        buttonClassName = 'button';
        buttonText = 'Book';
        handleOnPress = this.bookFlight
    }
    return (
        <button
            className={buttonClassName}
            onPress={handleOnPress}
        >
            { buttonText }
        </button>
    )
}

We can also use ternary expressions to have the same result as the one produced by code above:

renderButton() {
    // for className, you can also use this:
    // `button ${flight.cancelled ? 'disabled' : ''}`
    return (
        <button
            className={flight.cancelled ? 'button disabled' : 'button'}
            onPress={flight.cancelled ? null : this.bookFlight}
        >
            { 
                flight.cancelled ?
                    'Cancelled'
                    :
                    'Book'
            }
        </button>
    )
}

If you just want to render/pass something if the condition is fullfilled, you can also write it this way:

render() {
    return (
        <p>
            {
                // condition && what_to_render
            }
            { 
                flight.cancelled && 'Cancelled'
            }
        </p>
    )
}

Conditional rendering inside for loop

When rendering a list of items, you might want to render them differently based on some condition. For example, you might want to add grey background to all the even items. How to do this? You can either use ternary expression or standard if/else, both will work! Remember that it's a function like any other! Here's a small example:

render() {
    return (
        <div>
            {
                this.state.list.map((item, index) => {
                    // if even, render grey background
                    if (index % 2 === 0) {
                      // don't forget to return what you want to render!
                      return (
                        <div style={{backgroundColor: 'grey'}}>
                          {item.name}
                        </div>
                      );
                    } else {
                      // you can also use ternary expression
                      return (
                        <div style={item.expired ? {backgroundColor: 'red'} : null}>
                          {item.name}
                        </div>
                      );
                    }
                  })
            }
        </div>
    );
}

Of course, this mapping function can be extracted outside of render method, for increased readability.

Switch statement

We've been talking about if-else, but conditioning can, also, be done with a switch statement. Let's say that, instead of the boolean attributes for cancelled and arrived, we have one status attribute. Of course, we can't just type something like this:

render() {
    return (
        <p>
            {
                // this will raise an error
            }
            { 
                switch(flight.status) {
                    case 'cancel':
                        return "Cancelled";
                    case 'arrive':
                        return "Arrived";
                    default:
                        return "Regular";
                }
            }
        </p>
    )
}

For switch, there's no neat way to do it directly in return statement. We can, of course, use immediately-invoked function containing a switch, but it's neither practical nor does it look nice. To make the switch above work, just move it to some function outside of render method:

renderStatus() {
    switch(flight.status) {
        case 'cancel':
            return "Cancelled";
        case 'arrive':
            return "Arrived";
        default:
            return "Regular";
    }
}
render() {
    return (
        <p>
            { 
                this.renderStatus()
            }
        </p>
    )
}

Of course, switch can also be specified in render method, above the return statement. Just remember not to use 'return' in cases, but a 'break':

render() {
    let status;
    switch(flight.status) {
        case 'cancel':
            status = "Cancelled";
            break;
        case 'arrive':
            status = "Arrived";
            break;
        default:
            status = "Regular";
            break;
    }
    return (
        <p>
            { status }
        </p>
    )
}a

Now you're completely ready to do conditioning in React! Go ahead and try these out, make that code you've been struggling with for hours finally work properly!

If you already knew how to use if-else and switch in React, we hope you still enjoyed the article and freshened up your knowledge a bit.

Thank you for your time!

Originally published at Kolosek blog.

Rails RSpec Setup

Nesha Zoric — Fri, 01 May 2020 08:49:48 +0000

RSpec is an awesome tool for testing Rails apps. It is a hugely popular BDD-oriented (Behavior Driven Development) testing framework in the Ruby community.

It makes writing tests simpler, more expressive and easier to maintain!

Getting started

First, you'll need to install RSpec but you’ll also need Database Cleaner to help hold things together and ensure a clean state during tests. Add the following gems to the :test and :development groups in your Gemfile and then run bundle install:

group :development, :test do
  gem "database_cleaner"
  gem "rspec-rails"
end

It is very common to use RSpec together with Capybara to improve your testing development.

Configuring RSpec

Before you can start with writing your RSpec tests your will need to run rails generate rspec:install. This will create the following files:

create  .rspec
create  spec
create  spec/spec_helper.rb
create  spec/rails_helper.rb

Files such as, spec_helper.rb and rails_helper.rb contain the default RSpec set up with lots of comments. It is strongly recommended to read through all of those comments to get a good understanding of what each option does.

spec_helper.rb

spec_helper.rb file is used to configure RSpec. The base configuration file, after uncommenting some useful configuration options, is written in the following way:

RSpec.configure do |config|
  config.expect_with :rspec do |expectations|
    expectations.include_chain_clauses_in_custom_matcher_descriptions = true
  end

  config.mock_with :rspec do |mocks|
    mocks.verify_partial_doubles = true
  end

  config.shared_context_metadata_behavior = :apply_to_host_groups
  config.filter_run_when_matching :focus
  config.disable_monkey_patching!

  if config.files_to_run.one?
    config.default_formatter = "doc"
  end

  config.profile_examples = 10

  config.order = :random
  Kernel.srand config.seed
end

expectations.include_chain_clauses_in_custom_matcher_descriptions = true - Chain method allows custom matcher descriptions and failure messages to include text for helper methods.
mocks.verify_partial_doubles = true - Partial doubles prevent you from stubbing any methods that don’t already exist on an object, it typo-proofs your mocks.
config.shared_context_metadata_behavior = :apply_to_host_groups - Shared context metadata configures how RSpec treats metadata passed as part of a shared example group definition.
filter_run_when_matching - Filter run when matching allows you to limit a spec run to individual examples or groups you tagged with :focus metadata.
disable_monkey_patching! - Prevents RSpec from monkey patching makes objects behave in tests as they would in "real" life.
default_formatter - Default formatter sets up the default format of your rspec tests that will be used if no formatter has been set.
config.profile_examples - Profile examples print the slowest examples and example groups at the end of the spec run, but it slows down your suite
config.order = :random and Kernel.srand config.seed - Configure tests to run in a random order. This helps to keep each test independent of one another. ### rails_helper.rb rails_helper.rb file is used for specs which depend on Rails (mostly model and controller tests, but also on nearly every part of a Rails projects). ==rails_helper.rb requires spec_helper.rb to work.==

require 'spec_helper'
ENV['RAILS_ENV'] ||= 'test'
require File.expand_path('../../config/environment', __FILE__)
abort("The Rails environment is running in production mode!") if Rails.env.production?
require 'rspec/rails'

ActiveRecord::Migration.maintain_test_schema!

RSpec.configure do |config|
  config.fixture_path = "#{::Rails.root}/spec/fixtures"
  config.use_transactional_fixtures = true
  config.infer_spec_type_from_file_location!
  config.filter_rails_from_backtrace!
end

fixture_path - File fixture is a normal file stored in spec/fixtures by default.
use_transactional_fixtures - Transactional fixtures allow records created for one test to be visible for the next test.
infer_spec_type_from_file_location! - Allows to automatically tag specs in directories with matching type metadata so that they have relevant helpers available to them.
filter_rails_from_backtrace! - Backtrace filtering is used to filter out lines in backtraces that come from Rails gems in order to reduce the noise in test failure output. ##Configuring Database Cleaner By configuring the Database Cleaner in your application, you make it sure that tests start with a clean state. The only thing you need to do is to add the following to your RSpec.configure block in rails_helper.rb:

config.before(:suite) do
  DatabaseCleaner.clean_with(:truncation)
end

How to run the tests?

Once everything is configured you are ready to go! There are four ways to run your test:

Everything at once: bundle exec rspec. This runs all your tests.
One RSpec package: bundle exec rspec ./spec/models This runs all model specs.
One RSpec file at a time: bundle exec rspec ./spec/models/story_spec.rb. This runs only tests in Story model.
One by one: bundle exec rspec ./spec/models/story_spec.rb:10 This runs only tests on line 10 in Story model.

In the same way, you can run tests on your controller.

Be careful! The more tests there are the longer it takes to compile them. Only run tests for what you really need!

Originally published at Kolosek blog.

Are Lean and Agile enemies or friends?

Nesha Zoric — Wed, 29 Apr 2020 11:15:32 +0000

If you aren't an educated and/or experienced tech person, a lot of question marks may pop up in your mind while looking at these two terms: Lean and Agile. Even if you are technically proficient, you may wonder what the difference between these two really is. No worries, we are here to help you.
Both Lean and Agile are methodologies.
They are represented by sets of principles that used in order to guide the process of development (in this case, software development).
Although usually described as two completely different approaches, by the end of this post, you will notice that they are actually complementary and that one doesn’t exclude the other.

Lean

We will dare to say that Lean, generally speaking, has the process in its focus. The methodology behind Lean software development comes from Lean manufacturing. Here, it’s all about reducing any kind of a waste. By eliminating all that is unnecessary, the value is added, and value is what the customer is paying for.

Constant learning is a part of any process, and learning means improving. Without this, there is no quality, which is the final goal.

Also, people are important, because without a good team, how can you deliver a high-quality product? In order to have a smoothly running workflow, every member of the team should do what they can do best, and the work should be distributed evenly. The work is done more efficiently and quickly when everyone is doing their job, without unnecessary tasks (this can be tricky, because in our era, changes happen quickly, and something that was considered unnecessary yesterday, may tomorrow be crucial for the project).
There is a systematic, overall look at the work process when it comes to Lean methodology.

Agile

We will again be courageous enough to say that, generally speaking, in the focus of Agile is the product. Agile software development methodology is based on the Agile Manifesto. Four main values are in the center of the manifesto, and we quote them here:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.”

Communication among team members, both managers, and developers, is as important as the collaboration with the customer. A quality final product means a satisfied customer, and that is the goal.
From interaction, one is enabled to get a feedback. The feedback is attained after each cycle of the process (the working process can be seen as a compilation of smaller projects). This is crucial in order to make any necessary changes along the way, and in order to deliver the product in the short period of time possible.

Lean & Agile

These two methodologies are best described as complementary. Through quality work organization and quality team, a product of high quality is made, which makes a satisfied customer. The suggestion is that you should apply both of these methodologies. Collaboration between team members, listening to your customer’s needs, improvement and implementation of changes when necessary, elimination of any kind of waste in order to achieve high-quality and deliver the product without any unnecessary delays.

We hope that, after reading this post, you have managed to get a grasp of what both the terms Lean and Agile mean, and how they are applied in the process of software development. Our goal was to highlight the main points and deliver it in a way which is the easiest to read. However, there is definitely a lot more about these methodologies out there, and if interested, we strongly encourage you to dive into it and widen your knowledge.

Originally published at Kolosek blog.

React JSX - How to do it the right way - Part I

Nesha Zoric — Mon, 27 Apr 2020 12:20:15 +0000

Usually, when developing a website, you'll need some dynamical rendering, like a listing of items, showing some element under a certain condition and so on.
You're all aware of the standard JS syntax - a for loop, or an if/else - but when you try to write those under a render method in React, you'll most likely get some weird looking errors.

In this, the first part of React JSX series, we will take a look at how to correctly loop through arrays the reactive way. In second part of the series you can find out more about conditional rendering.

Please note that all of the examples below apply as well to React Native!

Using Loops Inside React Render Methods

Let's say you have an array of movies and that you need to display the Movie component for each of them.

Most of us have tried this at some point:

render() {
    return (
        <div>
            {
                // this won't work!
            }
            {
                for (var i=0; i < movies.length; i++) {
                    <Movie movie={movie} />
                }
            } 
        </div>
    )
}

This, however, won't work. Why? Think of it like you're just calling JavaScript functions. You can't put a for loop as a parameter when calling a function!

Well, how to do it then? There are a few ways.
You can go through a for loop above the return statement in render method and fill in a list you'll pass in return:

render() {
    const movieItems = [];
    for (var i=0; i < movies.length; i++) {
        movieItems.push(<Movie movie={movie} />);
    }
    return (
        <div>
            {
                movieItems
            } 
        </div>
    )
}

This, however, is not a neat way as it's polluting the render method. To make render more readable, better move the for loop outside of it and then call it as a function:

renderMovies(movies) {
    const movieItems = [];
    for (var i=0; i < movies.length; i++) {
        movieItems.push(<Movie movie={movie} />);
    }
    return movieItems;
}

render() {
    return (
        <div>
            {
                this.renderMovies(movies)
            } 
        </div>
    )
}

This looks a bit better now. Still, you are using the for loop which doesn't really look so nice. The for should be used when you need to render something a certain number of times. When you have an object or an array instead, there are neater ways.

So, let's switch to using the map from JS Arrays:

renderMovies(movies) {
    // This is ES6 syntax! You'll need babel configured to use it!
    // You can still use the standard function syntax,
    // but ES6 is definitely something that'll easen your life.
    return movies.map((movie) => {
        return (
            <Movie movie={movie} />
        );
    });
}

render() {
    return (
        <div>
            {
                this.renderMovies(movies)
            } 
        </div>
    )
}

Now, this looks good! Yet, it might look a bit bulky for being just a simple listing you can do in one single place. However, the map syntax you can actually use directly in a return statement. Why? Because the map function basically passes a freshly created array, compared to the for loop which is just a bulk of code.

render() {
    return (
        <div>
            {
                // This is shortened syntax, for where we don't need to manipulate the actual items before rendering them
            }
            {
                movies.map((movie) => <Movie movie={movie} />)
            } 
        </div>
    )
}

When you need to manipulate the actual item in the list before rendering it, you can do it this way:

render() {
    return (
        <div>
            {
                movies.map((movie) => {
                    // do something with a movie here
                    return (
                        <Movie movie={movie} />
                    );
                })
            } 
        </div>
    )
}

Now, again, if there's a lot of manipulating to be done for a single item, doing it inside a return statement might unnecessarily pollute the render method. In that case, better move this code out of the render method. Here's an example:

renderMovie(movie) {
    // do something with a movie here
    return (
        <Movie movie={movie} />
    );
}

render() {
    return (
        <div>
            {
                // map will automatically pass the list item to our function
            }
            {
                movies.map(this.renderMovie)
            } 
        </div>
    )
}

All of the previous can also be used for JavaScript objects, with slight adaptation - you won't be mapping through the object, but through the list of the keys of the object:

render() {
    return (
        <div>
            {
                // You can as well use lodash keys function (_.keys)
                // instead of Object.keys, but it functions the same way
            }
            {
                Object.keys(moviesObject).map((movieKey) => {
                    const movie = moviesObject[movieKey];
                    return (
                        <Movie
                            key={movieKey}
                            movie={movie}
                        />
                    );
                })
            } 
        </div>
    )
}

Keep in mind that all of the codes above are just examples, pseudo codes. Always send the key prop to the items you're rendering and keep it unique, avoiding array indexes.

Now you know multiple ways on how to loop through arrays in React! Which way you'll use is up to you and the occasion, sometimes one will be more suitable than the other.

Thank you for your time and good luck with coding!

Originally published at Kolosek blog.

Associations in Rails

Nesha Zoric — Mon, 27 Apr 2020 09:39:16 +0000

An association is a connection between two Active Record models. It makes much easier to perform various operations on the records in your code. We will divide associations into four categories:

One to One
One to Many
Many to Many
Polymorphic One to Many

If you are new to Ruby on Rails, be sure to get up your rails project ready and check how to create models in Rails.

One to One

When you set up one-to-one relations you are saying that a record contains exactly one instance of another model. For example, if each user in your application has only one profile, you can describe your models as:

class User < ApplicationRecord       class Profile < ApplicationRecord
  has_one :profile                     belongs_to :user
end                                  end

One of the models in the given relation will have has_one method invocation and another one will have belongs_to. It is used to describe which model contains a foreign key reference to the other one, in our case, it is the profiles model.

Cover your associations with RSpec tests to make sure everything works the way you want it to.

One to Many

A one-to-many association is the most common used relation. This association indicates that each instance of the model A can have zero or more instances of another model B and model B belongs to only one model A.

Let's check it out via example. We want to create an application where users can write multiple stories, our models should look like this:

class User < ApplicationRecord       class Story < ApplicationRecord
  has_many :stories                     belongs_to :user
end                                  end

Here, deciding which model will have has_many and which will have belongs_to is more important than in one-to-one relations, because it changes the logic of your application. In both cases, the second model contains one reference to the first model in form of a foreign key.

The second model doesn't know about the first model relation to it - it is not aware if the first model has a reference to more than one of them or just to one.

The tests for associations get more complex to write the more relations you create. You should check it out how to create your own association factories to make your testing life easier.

Many to Many

Many-to-many associations are a bit more complex and can be handled in two ways, "has and belongs to many" and "has many through" relations.

Has and Belongs to Many

A has_and_belongs_to_many association creates a direct many-to-many connection with another model. It is simpler than the other one, as it only requires calling has_and_belongs_to_many from both models.

Example: Let's say, a user can have many different roles and the same role may contain many users, our models would be like this:

class User < ApplicationRecord       class Role < ApplicationRecord
  has_and_belongs_to_many :roles       has_and_belongs_to_many :users
end                                  end

You will need to create a join table for this association to work. It is a table that connects two different models. The join table is created with rails function create_join_table :user, :role in a separate migration.

class CreateUserRoles < ActiveRecord::Migration
  def change
    create_table :user_roles, id: false do |t|
      t.references :user, index: true, foreign_key: true
      t.references :role, index: true, foreign_key: true
    end
  end
end

This is a very simple approach, but you don't have the direct access to related objects, you can only hold references to two models and nothing else.

Has Many Through

Another way to define a many-to-many association is to use the has many through association type. Here we define a separate model, to handle that connection between two different ones.

Instead of putting down a new example, you should check this one out! It explains everything you should know about this association.

Using the example of has_and_belongs_to_many association, this time the three models should be written like this:

class User < ApplicationRecord
  has_many :user_roles
  has_many :roles, through: :user_roles
end

class UserRoles < ApplicationRecord
  belongs_to :user
  belongs_to :role
end

class Role < ApplicationRecord
  has_many :user_roles
  has_many :users, through: :user_roles
end

This association will enable you to do things like user.role and to get a list of all connected second model instances. It will also enable you to get access to data specific to the relation between first and second models.

Polymorphic

Polymorphic associations are the most advanced associations available to us. You can use it when you have a model that may belong to many different models on a single association.

Let's imagine you want to be able to write comments for users and stories. You want both models to be commentable. Here's how this could be declared:

class Comment < ApplicationRecord
  belongs_to :commentable, polymorphic: true
end

class Employee < ApplicationRecord
  has_many :comment, as: :commentable
end

class Product < ApplicationRecord
  has_many :comment, as: :commentable
end

You can think of a polymorphic belongs_to declaration as setting up an interface that any other model can use. To declare the polymorphic interface you need to declare both a foreign key column and a type column in the model. You should run the migration once you are done.

class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.text :body
      t.integer :commentable_id
      t.string :commentable_type
      t.timestamps
    end

    add_index :comments, :commentable_id
  end
end

This migration can be simplified by using references:

class CreateComments < ActiveRecord::Migration
  def change
    create_table :comments do |t|
      t.text :body
      t.references :commentable, polymorphic: true, index: true
      t.timestamps
    end
  end
end

Aditional Options

There are a few additional options you can use when defining relations between models, we will cover two most commonly used ones.

class_name

If the name of the other model cannot be derived from the association name, you can use the :class_name option to supply the model name. You can read more about this on RailsGuides.

Example: You want the belongs_to relation to call for an author, but there are two problems:

There is no model called in that way.

The story table is missing an author_id field.

Easy fix! To make this work and stop your tests from failing, you just have to specify the :foreign_key and the actual name of the class:

class Story < ApplicationRecord
  belongs_to :author, class_name: 'User', foreign_key: 'user_id'
end

dependent

You can use this option when you want to get rid of orphaned records since they can lead to various problems. Orphaned records are created when we delete or destroy a model A that was associated with model B, but model B wasn't removed in the process.

class User < ApplicationRecord
  has_many :stories, dependent: :destroy
end

Example: Suppose, a user called Maria wrote a lot of stories. Then, we deleted Maria from the database, but the stories still have the user_id column set to Maria's id. These stories are called orphaned records.

Thank you for reading!

Originally published at Kolosek blog.

Agile and Scrum: Our Favorite Duo

Nesha Zoric — Thu, 23 Apr 2020 09:27:32 +0000

In our previous articles we wrote about Agile and Scrum, separately, and now we decided to mix them and bring together. If you want to know more, be sure to read those blog posts, and now, let's get to the the benefits of both of these productivity raisers.

Agile and Scrum

These two grew up in the same cocoon. Precisely, Agile is Scrum's older and wiser relative, similar to Rick and Morty.
As you probably learned by now, Agile is a philosophy, a concept that explains how a team should do a project, on a theoretical level. Agile describes principles, while Scrum is all about implementing principles by following the rules. Agile is a philosophy and Scrum a methodology.

Agile and Scrum - the similarities

The similarities are:

using an iterative approach of making a project,
adapting to change,
making improvements,
delivering the product on time. ## Using Scrum Scrum is not for everybody. I mean, it is, but you don't need it all the time. Here are some cases in which Scrum can help:
when you are about to do a large project,
when there is no deadline for an app to be delivered to the client,
when team members want more autonomy.

Not to sound rude, but Scrum is amazing for clients that change their minds quickly and are not sure what exactly they want because development team can easily adapt to that change.

Using Agile

Every time you think you need a project management concept, think of Agile. No matter for which method you decide to go with, Agile, as a philosophy, is the way to go.

In the end...

... Agile and Scrum are inseparable. They go like hamburger and french fries. Not from McDonald's. From some fancy restaurant that sells hamburgers. Delicious!

If you want to know more about Agile, also check out our post on Agile and Lean.

Hope you learned something new today.

Originally published at Kolosek blog.

How to Plan and Build a Profitable Mobile App?

Nesha Zoric — Wed, 22 Apr 2020 09:22:54 +0000

There are currently almost 10.000.000 mobile apps available in the leading app stores.

Yes, there are 10 million pieces of software on the market. And there’s always someone thinking about making a new one. An app that’s going to kick the others out of the game, become super popular and make a ton of money in the process. If you’re one of the people with such thoughts on their mind, then this short guide is for you.

We’ll go through exactly what you need to think about before even starting the project, and then we’ll explain how to start it off on the right foot.
However, if your idea is to build a mobile game, then this post is not for you. The game industry has different rules and nuances you need to learn about. It might be a topic of some other post on this blog, but not this one.

So, let’s get down to business.

How to make sure my mobile app will be successful?

1. Is your app solving a problem?

This might seem like common business sense, but quite often we see enthusiastic people on their way to build an app they believe in without actual need. What does that mean? Well, either they or someone they know encountered a specific problem, and they feel they could easily solve it with an app.
That’s a great starting point for any business - identifying a problem, a pain point, that you can find a solution for. But, it’s a terribly bad idea if you don’t do a couple of things before running into a demanding venture.
If you think you have a perfect solution for your aunt Gracy’s cat’s problem, first make sure that other cat owners are struggling with the same issues. Your aunt and her friends aren’t a very large user pool. So, once you’ve identified the problem, you need to do your research.
Are there really enough potential users? You don’t need to find 10.000 people, a small relevant sample will do. Find an online venue (Facebook group, Twitter, email list…) where your target group gathers and give them a questionnaire in a form that works best for you. Use this to find out exactly what they’re struggling with and how they’re solving it. You can also use this as an opportunity to gather your initial user group. At the end of the questionnaire, offer to let them know about your launch (or offer a discount) in return for their email address or phone number. This will come in handy since you'll have qualified leads before you even have the final product.

Recap:

Is it a real problem?
Are there enough potential users to make the app profitable?

2. Who else is solving the same problem?

With millions of mobile apps out there, it's very likely someone else is trying to do the same thing. Find them and research them thoroughly.

How are they approaching the problem? How successful are they? For how long have they existed and how big is their user base?
If they failed, why and how did it happen? You can do the research on Startup graveyard and autopsy.io. These two handy websites will give you a bunch of stories about startup failure. They're not meant to demotivate you, but to help you know what to look out for. There's also a /r/shutdown subreddit, if you prefer this platform for getting your information.
Take a close look at your competitors and find their weak points. Are they failing their users in an important area? Is their service excelling at something particular? Use them as a great source of information and gather as much as you can.
Maybe your service will be complementary to theirs and you can actually partner up? Keep your mind open to such options.

Recap:

Go into depth when researching your competitors.
Keep your mind open to "unconventional" possibilities.

3. What is going to hold you down?

Are there any legal implications you should be aware of? If you're tapping into a niche that's rigorously regulated, you need to talk to an expert before you proceed any further.
If you'll intend to collect any personal data from your users, how will you enable security and privacy protection?
No matter what you're doing, it's good to have a lawyer and an IT security expert at least as consultants.

Recap:

Legal and security aspects are very important.

4. How will you monetize it?

It's a decision you need to make early on as it will determine the profitability of your project.
Are you going to charge for the app? Will you go with the free app + paid upgrades? If you're not an expert in the pricing area, then this is something to discuss with your team or a professional consultant. You need someone who is experienced in the industry.
There is more than one tool you can use for this including Google AdMob and Facebook Audience Network.

Recap:

Think about the money.

5. It's a project

Developing an app should be taken as a serious project. And a serious project means there is serious management. You need to plan carefully and find the best team possible. That is not the easiest task if you're just starting out and don't really have much money to throw at this project.
If you're a developer yourself, you'll most likely need a marketing and sales person. Also, another developer for peer review always comes in handy. Make sure you know where you're going with the app and give yourself deadlines. The next step is to actually try and follow those deadlines. Seriously.
If you're not a developer, you'll need at least one, depending on the complexity of the app. Make sure you choose carefully. We wrote about that in our blog post about outsourcing. The same principles can be used if you're a non-tech person who's picking a developer.
Either way, put it all on paper, be honest about what you can(not) do and find the holes you can't fill. Then look for people who could help you on your journey. One can do very little on their own. You DO need a team, no matter how small it is in the beginning.
If you can't pay for them, you can offer them a percentage of ownership. Or you can find a different deal that is going to work for everyone.

Recap:

Take your project seriously.
Hire a team.
Try and stick to the deadlines.

All in all, it is going to be a bumpy ride for you (and your teammates). Buckle up, get ready and good luck!

Originally published at Kolosek blog.

Delegate in Rails

Nesha Zoric — Tue, 21 Apr 2020 09:59:23 +0000

A model should only talk to its immediate association. According to the Law of Demeter, you shouldn’t talk to the association’s property or association’s association.

Here we talk about Rails delegate approach.

BAD SMELL

class Profile < ActiveRecord::Base
belongs_to :user
end

<%= @profile.user.address %>
<%= @profile.user.city %>

Rails provides helper method to accomplish delegation, which uses DSL to generate wrapper methods. It can also prevent error call method on nil object if :allow_nil => true is added.

Refactored

class Profile < ActiveRecord::Base
  belongs_to :user
  delegate :address, :city, :to => :user, :prefix => true, :allow_nil => true
end
<%= @profile.user_address %>
<%= @profile.user_city %>

Originally published at Kolosek blog.

line-height in CSS

Nesha Zoric — Wed, 15 Apr 2020 12:54:56 +0000

The CSS property line-height defines the amount of space used for lines, most commonly in the text.

It is often confused with line spacing (leading) used in Photoshop and similar softwares.

Leading is a term that describes the distance between the baselines in the text. In the case of defining leading, space is always added below the text. But, when working with line-height property, space is always added equally above and below the text.

Line-height uses several different types of units:

px,
em,
%,
unitless number,

It’s important to mention that the unitless value is, basically, just a percentage. So, if the line-height has a property of 1.2, it means it just has a value of 120%.

Importance of line-height

The most important use of line-height is making your text readable. It is recommended to use unitless values of any other unit that isn’t static like the px unit.

If there is a need to set the font size and line-height at the same time, there is a handy CSS shorthand:

html {
  font: 24px/1.5 ‘Lato’, sans-serif;
}

By using this shorthand you will be able to set 3 elements at the same time:

font-size,
line-height,
font-family.

The line-height property applies only to elements that have their display property set to inline or inline-block. If the line-height is set on a block element, there might be some changes, but it is probably just the inline child elements that have been affected.

If you set the line-height without a unit, the result is the line-height value multiplied by the element’s font-size.

div {
  Font-family: ‘Lato’, sans-serif;
  Font-size: 14px;
  Line-height: 2 // equals to 28px
}

Hope this article helped clarify the meaning and usage of the line-height property.

Thank you for reading!

Originally published at Kolosek blog.

9 Ruby on Rails Blogs to Follow

Nesha Zoric — Tue, 14 Apr 2020 08:55:40 +0000

If you’re a Rails developer (or aspiring to become one), you know how important it is to stay up to date with all Ruby related news. It can sometimes even be overwhelming because there are so many sources of information online. It can be hard to determine which ones are actually legitimate.
Also, every developer appreciates the help of a community. Problems are solved much faster with other people’s experience.
So, here are the best everyday reads for busy a Ruby on Rails developer who wants to keep up.

1. Ruby Weekly

We all hate boring and spammy newsletters. This is definitely not one of them. Ruby Weekly is very concise, to the point and current. They will deliver one newsletter to your inbox per week, and it will be packed with useful info, no matter what you do with your Ruby code.
There’s a sample issue of the latest newsletter so you can take a look at that before deciding whether you want to give them your email address.

2. Everyday Rails

This blog has been around for a while now. It’s not updated regularly, but it’s packed with useful stuff, especially if you’re into testing. It also contains a lot of handy tips you can use to make your workday easier.
The blog has a “get things done” approach and that’s probably what we like most about it.

3. The Official Rails Blog

Well, of course. We recommend the official RoR blog for timely updates about the framework. It contains all the relevant changelogs for the gems.
There’s also a “This Week in Rails” section with practical tips from developers.

4. /r/ruby

If you’re not already using Reddit as a channel for learning about development, it’s high time you got started.
/r/ruby is a lively community full of people who are ready to share their knowledge (and their frustrations)

5. Drifting Ruby

This is a screencast and a blog which is updated fairly often. So, if you’re a fan of learning things visually, this is a great place.
The website is run by a Rubyist Dave Kimura.

6. RailsCasts

While we’re at screencasts, we have to mention the RailsCasts.
This website hasn’t been running for a while now, but the archives are definitely worth the visit, especially for someone who’s just starting out.

7. Ruby Inside

This is another blog with news and tutorials that haven’t been updated in the past few years. Again, the archive is more than valuable for issues we’re facing today.

8. Go Rails

Another one for visual learners. GoRails YouTube channel is updated weekly and contains detailed tutorials. Most videos are just a few minutes long, but the longest you’ll spend on a single video is around 20 minutes.

The description of the screencasts states they are there to “fill in the gaps, explain the confusing pieces, and give you an understanding you can't find elsewhere”.

9. Ruby Flow

If you enjoy the concept of HackerNews, you’ll like Ruby Flow. It’s just the community, pushing out the content they find most useful.

What should we add to the list? Share your favorite blogs, YouTube channels, subreddits or other sources you use for Rails in the comments below.

Originally published at Kolosek blog.

Rails Scaffold

Nesha Zoric — Thu, 09 Apr 2020 12:19:50 +0000

Scaffolding in Ruby on Rails refers to the auto-generation of a set of a model, views and a controller usually used for a single database table.

For example, you can auto-generate a ready to use controller, model, and views with a full CRUD (Create, Read, Update, Delete) web interface for the Story table using the following command:

$rails generate scaffold Story title:string content:text

It's way easier to do this, instead of coding everything yourself, it saves you a lot of time!

Scaffold or Models?

Compared to the scaffold that generates everything that you need (and don't need), models create only some related components. The best, and my favorite, way to explain the difference between scaffold and models is by using the following example:

Generate models

Once you enter the command $rails generate model Story title:string content:text you will generate:

invoke  active_record
create    db/migrate/20180205103025_create_stories.rb
create    app/models/story.rb
invoke    test_unit
create      test/models/story_test.rb
create      test/fixtures/stories.yml

invoke active_record will tie your model to the database, while the next line creates a migration file. Migrations are used to alter your database schema. This migration file creates the database table called 'stories', and database columns for "title" and "content".

The third line will create a model - a Ruby class that inherits the Active Record. With this, every method that can be called in Active Record can now be called in your model. The last three lines create related test files for your model.

While scaffolding will get you up and running quickly, the code it generates is unlikely to be a perfect fit for your application. You’ll most probably want to customize the generated code. Many experienced Rails developers avoid scaffolding entirely, preferring to write all or most of their source code from scratch. You can read more about this on RailsGuides.

As you can see, generate models does not create any kind of view to display information on a page. To have a complete, ready to use application, you would need to:

generate controllers (which in turn generates views, as well) or

generate scaffold (which generates your model, views, controller and writes to your routes.rb file).

If you change your mind and decide to use scaffold after already generating the model, you can always run $rails generate scaffold <name>. It will create all the missing files.

Generate scaffold

If you enter the command $rails generate scaffold Story title:string content:text you will generate the following files:

invoke  active_record
create    db/migrate/20180205103508_create_stories.rb
create    app/models/story.rb
invoke    test_unit
create      test/models/story_test.rb
create      test/fixtures/stories.yml
invoke  resource_route
route    resources :stories
invoke  scaffold_controller
create    app/controllers/stories_controller.rb
invoke    erb
create      app/views/stories
create      app/views/stories/index.html.erb
create      app/views/stories/edit.html.erb
create      app/views/stories/show.html.erb
create      app/views/stories/new.html.erb
create      app/views/stories/_form.html.erb
invoke    test_unit
create      test/controllers/stories_controller_test.rb
invoke    helper
create      app/helpers/stories_helper.rb
invoke      test_unit
invoke    jbuilder
create      app/views/stories/index.json.jbuilder
create      app/views/stories/show.json.jbuilder
create      app/views/stories/_story.json.jbuilder
invoke  assets
invoke    coffee
create      app/assets/javascripts/stories.coffee
invoke    scss
create      app/assets/stylesheets/stories.scss
invoke  scss
create    app/assets/stylesheets/scaffolds.scss

Once model related tests are created, the next line will generate resource routes to your stories. After generating resource routes comes the controller and its actions (index, show, new, edit, create, update and destroy), together with views and controller tests for each of this actions.

The Rails router recognizes URLs and connects them to a controller's action. By default, a controller's action will render a view of the same name.

Migration

Every time you create a migration using scripts (generate model/generate scaffold) a new migration is added to the correct directory. You use $rake db:migrate to checks which migrations that have not been added to the database.

== 20180205103508 CreateStories: migrating ====================================
-- create_table(:stories)
   -> 0.0007s
== 20180205103508 CreateStories: migrated (0.0008s) ===========================

Destroy

Everyone is free to edit and do the necessary changes to their application to work as intended, even if it means completely removing scaffold. You can remove scaffold in the following way:

Generate scaffold: $rails generate scaffold Story
If you migrated your files, perform a rollback: $rake db:rollback
Destroy or undo scaffold: $rails destroy scaffold Story

By doing this, you will delete all the files created by the scaffold but additional changes that you may have done manually will not be removed.

Conclusion

A scaffold is excellent to use when it comes to simple examples, quick mockups or testing. However, be sure to generate your own models when you decide to develop a new application. Don't forget to always test your application, find out how to do it by using Capybara!

We hope you discovered something new today!

Originally published at Kolosek blog.

CSS Position Relative vs Position Absolute

Nesha Zoric — Fri, 03 Apr 2020 08:27:48 +0000

The CSS position property defines, as the name says, how the element is positioned on the web page.

If you are interested in reading about the font properties, articles about the relative font size and CSS columns might be of interest.

So, there are several types of positioning: static, relative, absolute, fixed, sticky, initial and inherit. First of all, let’s explain what all of these types mean.

Static - this is the default value, all elements are in order as they appear in the document.
Relative - the element is positioned relative to its normal position.
Absolute - the element is positioned absolutely to its first positioned parent.
Fixed - the element is positioned related to the browser window.
Sticky - the element is positioned based on the user’s scroll position.

Now that we have explained the basics, we will talk more about the two most commonly used position values - relative and absolute.

What Is Relative Positioning?

When you set the position relative to an element, without adding any other positioning attributes (top, bottom, right, left) nothing will happen. When you add an additional position apart from relative, such as left: 20px the element will move 20px to the right from its normal position. Here, you can see that this element is relative to itself. When the element moves, no other element on the layout will be affected.

There is a thing you should keep in mind while setting position - relative to an element limits the scope of absolutely positioned child elements. This means that any element that is the child of this element can be absolutely positioned within this block.

After this brief explanation, we need to back it up, by showing an example.

In this example, you will see how the relative positioned element moves when its attributes are changed. The first element moves to the left and top from its normal position, while the second element stays in the same place because none of the additional positioning attributes were changed.

HTML

<div id=”first_element”>First element</div>
<div id=”second_element”>Second element</div>

CSS

#first_element {
  position: relative;
  left: 30px;
  top: 70px;

  width: 500px;
  background-color: #fafafa;
  border: solid 3px #ff7347;
  font-size: 24px;
  text-align: center;
}

#second_element {
   position: relative;

   width: 500px;
   background-color: #fafafa;
   border: solid 3px #ff7347;
   font-size: 24px;
   text-align: center;
}

What Is Absolute Positioning?

Absolute positioning allows you to place your element precisely where you want it.

Absolute positioning is done relative to the first relatively (or absolutely) positioned parent element. In the case when there is no positioned parent element, the element that has position set to absolute will be positioned related directly to the HTML element (the page itself).

An important thing to keep in mind while using absolute positioning is to make sure it is not overused, otherwise, it can lead to a maintenance nightmare.

The next thing, yet again, is to show an example of absolute positioning.

In the example, the parent element has the position set to relative. Now, when you set the position of the child element to absolute, any additional positioning will be done relative to the parent element. The child element moves relatively to the top of the parent element by 100px and right of the parent element by 40px.

HTML

<div id=”parent”>
  <div id=”child”></div>
</div>

CSS

#parent {
  position: relative;

  width: 500px; 
  height: 400px;
  background-color: #fafafa;
  border: solid 3px #9e70ba;
  font-size: 24px;
  text-align: center;
}

#child {
  position: absolute;
  right: 40px;
  top: 100px;

  width: 200px;
  height: 200px;
  background-color: #fafafa;
  border: solid 3px #78e382;
  font-size: 24px;
  text-align: center;
}

Through these examples, you have seen differences between absolute and relative positioned elements.

We hope this article clarified some doubts related to absolute and relative positioning and will help in any future projects.

Check out other detailed articles related to CSS properties such as this one: CSS Positions, SASS and LESS Nesting.

Originally published at Kolosek blog.