DEV Community: Our Time For Tech

Demo Day!

Gabrielle Easton — Wed, 16 Jun 2021 23:55:19 +0000

Last month my fellowship with CodeCollab came to an end. It was a great opportunity to grow as a developer. The fellowship was full of learning.

I collaborated with a diverse team. We all gained experience not only working remotely – quite useful nowadays – but also working in different timezones (9 hours apart).  We used GitHub as our collaboration tool. We used GH to keep track of the code and as a task manager. We had all the tasks, features, and bugs we needed to take care of and we held most of the discussions about them there. 

I learned how to prioritize tasks and manage workloads.
I also learned how to be confident working with the tech stack that I wasn’t familiar with. It was intimidating at first, but then I realized that all the frameworks have something in common.

I also got to experience the power of testing. It became one of my favorite parts of the development process. I learned how to give empathetic feedback and receive feedback with grace. It was difficult to review someone else’s work at first, but it became easier with more experience. I learned how to take ownership of the App as well.

We finished our fellowship with Demo Day. It was a great way to show a tech community what we had developed and how much we had learned and grown from the experience. I most appreciated how much you can learn from a team with many different backgrounds and experiences.

Now is to the next adventure!

Cheers!

Photo by Jason Leung on Unsplash

Reflections Of A CodeCollab Fellow

Deborah Bello — Thu, 27 May 2021 16:26:44 +0000

It’s Demo Day!🎉

Generally, I’m grateful to be a fellow in CodeCollab Cycle 2.
We had two weeks of Testing the App before Demo week and it was such a learning experience for me. It gave me a deeper understanding of its importance and how it can make you a better dev.

In Our case, we did the testing after building the app so we had to test the methods we already had in place. Writing Tests helped us to see the faults in the App and minimize the breaking changes in the app(as that’s what they are for, isn’t it?😁). One of the major things, writing tests helped me understand is that the final goal isn’t to make the test pass but to make sure the test is testing what you’re meant to test.

I also appreciate how writing tests is very encapsulated, in the sense that writing tests for one controller(e.g shifts), doesn’t affect another controller(e.g workers). Testing is definitely something I look forward to doing more.
I also learned how it’s beneficial to communicate Coding Fatigue effectively when you are experiencing it. Coding Fatigue allows you to miss out on your little mistakes and hence, makes you stuck. It’s real and a normal thing that happens to devs but it becomes a problem when it’s not properly communicated with your team members.

It’s okay to be tired. It doesn’t mean you’ve lost your competence. ~Arit

Overall, I’m glad at how much my teammates and I have grown in our professional team communication, collaboration, and technical skills in the past 12 weeks. This Cycle is gonna be a wrap at Demo Day and it’s one that gives me mixed feelings. 😅
Thank you for the honor of reading and staying through on the CodeCollab Cycle 2 journey with this blog!❤️

Reflecting on writing tests

Gabrielle Easton — Wed, 19 May 2021 15:13:45 +0000

During the last few weeks, I was occupied with writing tests for our application. My biggest surprise was to find that I enjoy writing tests. Now I can fully understand the importance of having tests in your application. Tests have the power to minimize the breaking changes to the app and helps to build a stronger application.

Personally, it helped me to understand the application we designed better. I can see now why writing tests make you a better developer. By writing tests and seeing that some of them have failed, we have improved our codebase. I also loved that writing tests give you the freedom to work independently on the part of the app you are testing.

This time we didn’t follow strict TDD practices. First, we built the features, and now we are testing them. It gave us an advantage of seeing the App live. It’s not a common approach, but it provided us a better understanding of what we are testing.

Big shout-out to Arit for the opportunity to learn how to write tests and the importance of it, and sharing her love for writing tests. Her enthusiasm is very motivating.

My first Unit Testing experience

Sara LoG — Fri, 14 May 2021 16:24:27 +0000

These past two weeks has been "testing weeks" at our Time for Tech codeCollab and we all have been writing test for the different parts of our Shiftwork App.

Despite having worked as a developer for a few years in the past, this has been the first time I had properly written a test by myself. Back then I used to hear about their importance in meet-ups and in conferences but the reality was that we never had enough time / interest to put them in place as part of our processes.

Even if they are far more common now than 4 years ago I think that is still a problem in some companies and I have both types of former colleagues and acquaintances: the ones that think that they are not so necessary and the ones who think you can't be a good dev if you cannot write tests.

As I have survived all this time without them I used to consider them as a "nice to have". But this experience has given me a more deeper understanding of their importance and how they actually can make you a better dev.

Not only I found flaws that might have gone unnoticed (that's what are they for, aren't they!) but they also require you to have a very good knowledge of the app, what should do and what shouldn't and above all understand that the important thing is not making the test to pass. The final goal is to make sure the test is actually testing what you are meant to test.

In this case we did the testing after building the app so we had to test the methods we already had in place. Although writing the test before would have been a very good experience too, I'm glad we took this direction as I have much more understanding of the app, its parts and behaviour now than when we started 10 weeks ago, and as a first testing experience for most of us a TDD approach would have been very intimidating. Now I'm ready for it tho!!!

And after this, I'm currently thinking of the next challenge: presenting The Shiftwork App to the public in our demo day. So if you want to support us at our virtual event, please Grab a free ticket here!

Hope to see you there!

Reflecting on handling workloads

Gabrielle Easton — Fri, 07 May 2021 17:41:10 +0000

As we continue working on the Shiftwork App, the workloads are becoming very heavy. Every day there are new bugs that we discover, PRs that are up to review, and with all of that, you need to continue working on your assigned tasks which a lot of times include the research before the implementation. I am learning a lot about handling my workload.

I enjoy working in a fast-paced environment. It gives me a feeling of drive and empowers me to own the project. With that comes the challenge of managing your time and learning how to prioritize your work to complete all the tasks and make sure you deliver quality results.

Our team has a great structure in place. We have set ways of communication, daily stand-ups, and weekly meetings. This helps a lot to stay focused and be aware of the scope of the project.

When it comes to independent work, I've realized I need to do more to stay productive. I schedule the tasks I will be working on the night before. I move uncompleted tasks to the next day. I plan the most complex task to be done at my most productive hours. Yes, knowing your most productive hours can be a lifesaver. I remember to reach out to my team if I am blocked on anything with the project. I see the importance of daily stand-ups and keeping close communication with my team.

And most importantly, I learn to remember to take breaks and spend time away from the computer. My way to recharge is to get out into nature. I take regular walks at East River Park in my local neighborhood. Planning, prioritizing, and not forgetting about rest are the ways to stay healthy and be a productive engineer.

Photo by José Martín Ramírez Carrasco on Unsplash

Announcing Demo Day! 🎉

Arit Developer — Wed, 05 May 2021 17:18:02 +0000

For almost 12 weeks, as part of our CodeCollab track, early-career developers Timi (@timilehin08), Gabrielle (@gabrielleeaston), Sara (@saradotlog) and Cam (@dordsichord) have been building The Shiftwork App from scratch.

The process has been exciting. 🥳

It has also been challenging. 😭

Above all, this project has expanded the team's technical, communication and collaborations skills like never before.

On March 27th, the team shall present The Shiftwork App at Our Time For Tech's first-ever Demo Day!

And YOU are invited!

Grab a free ticket here and please show up to support our hard-working fellows! 🙏🏾

At the virtual event, the team will summarize the app's features, share on what they learned and how they grew, and entertain questions from the audience.

We hope you will join us! 🧡

Collaboration Skills

Gabrielle Easton — Wed, 28 Apr 2021 02:11:23 +0000

The idea of the CodeCollab is a collaboration, how we work together, how we communicate, and our dynamics in how we interact. Our senior developer reminds us of this each sprint meeting when we start to get frustrated. The idea seems easy enough, but in reality, it can be challenging to collaborate with others. Each person on a team has communication preferences, different time zones, different backgrounds, and personal goals.

As I am learning, collaboration won't happen without clear communication, actively listening to others, taking responsibility for mistakes, and respecting the diversity of your teammates. It is also helpful to continuously develop asynchronous communication and give clear context to the question you are asking with an empathetic tone. So far, I see a lot of growth happening in myself and my team as we continue collaborating on the ShiftWork App.

We hold regular meetings, so we have a shared and clear vision of the direction we’re going. Each of us knows the full scope of the project and what we’re accountable for. We use GH collaboration tools for these purposes. This allows each of us to perform efficiently. What’s obvious for you isn’t always obvious for others. Speaking up and sharing ideas are essential to solving problems as they arise. I am always amazed at how much you can learn from a short conversation with your team. Each person will bring different perspectives and views. Constant communication ensures that everyone is on the same page. It’s fuel to keep the creativity of the development process alive. Team collaboration drives creative thinking and effective brainstorming. It allows you to look at problems from multiple angles and points of view.

It's necessary to learn how to understand various perspectives and manage priorities from everyone in the group. I am learning how to give and receive feedback. I am learning to assume that the person giving feedback has the best intentions. When I give feedback, I try to give it clearly and with consideration.

I can say with confidence that my team has what is needed to collaborate successfully. We have a cooperative spirit and mutual respect.

Photo by Mitchell Luo on Unsplash

How It’s Going

Deborah Bello — Mon, 19 Apr 2021 11:24:11 +0000

Another week in Our Time for Tech has gone by. In the past week, we had a variety of discussions as regards the development process.

First, we had to stop the use of the Devise Gem and the reason was that as we worked further on different features of the App, it was seen (with our Senior Engineers’ help) that it is too complex to fit into the needs of our App. This caused us to have another version of the App on the GitHub repo, of which everything has been running smoothly so far.

This also taught me that;

“Just because something is popular doesn’t mean that it’s going to fix your current project.” - Arit

Additionally, we decided to reduce our App’s MVP by removing the worker-slots feature which allows businesses to alert workers as regards their availability which is specific for upcoming shifts. The removal of this feature was because working on this is far more complex for the time we have which is now less than 7 weeks, including QA(Quality Assurance/smoke testing) and User feedback.

Furthermore, I learned how important it is to document/write down your progress in whatever you’re learning as it helps you to communicate effectively what you’ve done, which is a vital skill for a developer.
We were also advised and told of the importance of keeping our PRs(Pull Requests) small due to its efficiency and how it makes reviews easier. Everybody likes Small PRs while Long PRs are not liked as they are known to stay for a long time.

Currently, we’re all working on the UI styling of the App of which we are using SASS and Bootstrap which gives us readable code. In advance, I’m excited about how the guide on using the MiniTests Library is going to look like. As promised by Arit, a collaboration is ongoing with her and Chris Oliver Of GoRails in creating the guide for the testing of the App.

I’m also glad about how my team and I (now 4 of us) have improved on collaborating, communicating more effectively, and growing together.

Some Noteworthy points I learned in the past week:

“It’s great to be comfortable with uncertainty”.
“Uncertainty is something that’s part of a developer’s life.”
“Get comfortable with being uncomfortable”
“Assume best intentions when giving and receiving feedback.”

I’m looking forward to more learning and excited to see where we go from here. Thanks for reading!

Follow along with DEV posts from my cohort:
https://dev.to/ourtimefortech
Check out Our Time for Tech:
https://ourtimefortech.org/

Photo by Ilya Pavlov on Unsplash

Lessons from PostgreSQL

Deborah Bello — Mon, 19 Apr 2021 10:37:55 +0000

Hello there! Today, I’ll be talking about some noteworthy lessons I learnt while using PostgreSQL for Our Shiftwork App.
As much as we didn’t go in-depth using PostgreSQL on the App, they were still quite some things to learn using PostgreSQL.
For the Shiftwork app, my team and I are building, the major thing PostgreSQL was to do was in creating the database.
As I had said before in my blogpost here, I jumped from one error to another trying to get the database to be created with most of my issues; PostgreSQL related.

PostgreSQL Power

Postgres is an incredibly powerful database that’s packed with many different features. Some of its most interesting and productive capabilities, however, aren’t always evident.
When we started the initial setup of the app, I wondered why we chose PostgreSQL over MySQL, but I got to learn that PostgreSQL is a superior choice over MySQL based on its rich features, active community, and support.

As much as PostgreSQL and MySQL are both immensely popular open-source databases, and a variety of real-time applications today utilize both. MySQL is known to be the world’s most popular database, whereas PostgreSQL is known as the world’s most advanced RDBMS database(Relational Database Management System).

As an RDBMS database, MySQL is not fully SQL compliant and does not have many of the features that PostgreSQL has. This is why PostgreSQL has become a great choice for developers, and its popularity is growing exponentially with each passing day.
PostgreSQL also makes setting up and using databases easier and simpler both on-premises or in the cloud. PostgreSQL can also be a very good data warehouse for running complex reporting queries and procedures on large volumes of data.

PostgreSQL is an easy-to-use database with its full stack of RDBMS database features and capabilities that can handle structured and unstructured data. Installations can be easily done on Linux-flavored environments using yum or source code from the PostgreSQL website. Installing from source code gives you much more fine-grained control over the installation.
Just as it’s the same with Rails, I learned that a lot can be going under the “hood” despite how deceptively easy it might be to use.

Another thing I learned was that there are no “users” in PostgreSQL, just roles.
By running psql Postgres in your terminal, you’ll automatically log in with your username to PostgreSQL, therefore accessing the role created. Once a role is created, you can see it by using the \du command.

The following roles attributes are seen by default:
Superuser
Create role
Create DB
Replication
Bypass RLS
and it’s possible not to be a member of any of the roles (Herein lies some of the major errors that might be encountered with PostgreSQL).

Creating a new role
A new role is created using the CREATE ROLE command:
CREATE ROLE <role>;

Quick Summary of useful commands in postgreSQL
sudo -u Postgres psql
postgres=# create database mydb;
postgres=# create user myuser with encrypted password 'mypass';
postgres=# grant all privileges on database mydb to myuser;

As I had to consume some documentation and go through resources, I learned a tip which is the importance of reading the PostgreSQL Manual. The official documentation (or docs as they are referred to in short) of any product is the best place to find the largest wealth of information.

The Little Things

I remember running into this bug, “ActiveRecord::AdapterNotSpecified: 'PostgreSQL database is not configured”, “Rails Aborted” when I was trying to migrate into the database.
After checking and trying several solutions on StackOverflow, I found out the problem was because there was a space before development in the db config file.
This was fixed by simply removing space from the first line and following the indentation. This got me past my hour+ blockade as I didn't know leading spaces were an issue. Haha funny, isn’t it?

From here I learned that:

“It can be the simplest things that can cause the most aggravating errors.” - Arit Amana

Below are some links to the helpful resources/documentations I used with the bugs I encountered, if you desire to know more:

While I initially felt quite anxious and tired about how I kept running into one error from another, I’m glad that it has helped foster my learning process. I hope to learn more facets of PostgreSQL soon! Thank you for reading!

Referencing:
https://www.enterprisedb.com/blog/postgresql-vs-mysql-360-degree-comparison-syntax-performance-scalability-and-features

Photo by Christopher Gower on Unsplash

Development process

Gabrielle Easton — Wed, 14 Apr 2021 14:59:12 +0000

Last week we had a number of different discussions about the development process.

One of the discussions was about the work-slots feature.
The work-slots feature allows businesses to alert workers with specific availabilities about the upcoming shifts. As we only have eight weeks left that need to include QA and user feedback, we decided to reduce our App's MVP. We decided to remove the worker slots feature because implementing this feature is far more complex for the time we have.

Another topic we discussed was styling. We will be using SASS and bootstrap. I am very excited to take advantage of SASS to keep the code readable.

During our discussion, I discovered that there will be a collaboration between Arit and Chris Oliver for testing the App. They promised to put together a guide on using the MiniTest library. I can't wait to see the results.

Once again, we promised to keep our PRs small. Everybody likes small PRs, and it's more efficient and easier to review.

A note about devise gem: as we went further working on different features of the App, we realized (with a help of senior developers) that the devise is too complex to modify to the needs of our App.

I think these moments are best for learning. You understand how quickly things get complex in a considerably small application. Discussing and researching is a big part of development.

Hooray! I kept it short this time! Thanks for reading!

Photo by John Schnobrich on Unsplash

The World Of Testing

Deborah Bello — Tue, 13 Apr 2021 23:14:21 +0000

As much as I wasn’t the one in the team that started working actively and researching on the issue created that would have to do with Testing later on, it was still definitely important that every one of us on the team knew what testing is all about, as it is an important skill for a developer and we would split the test writing tasks among ourselves in few weeks to come.

Before my research on understanding the importance of Testing and the different approaches to it, The idea of creating Tests felt very intimidating a skill to learn. This was probably because I had no former experience in it and from hearsay’s, it seemed hard, and not a joyful thing to do. However, I decided to see it as a learning ground and stepping stone into the world of Testing.

What are Tests?

These are scripts that produce a consistent result and prove that an application does what it is expected to do. Tests are developed concurrently with the actual application.
Often what to include in functional Tests(controller testing) are Testing for things such as:

Knowing if the web request was successful?
Knowing if the user was redirected to the right page?
If the user was successfully authenticated?
If the correct object is stored in the response template?
If the appropriate message is displayed to the user in the view?

An important piece of advice I learned in the documentation is to include a test for everything which could break and that it is best practice to have at least one test for each of your validations, and at least one test for every method in your model.

Approaches to Testing/Testing in Rails
In learning on testing, I saw different approaches, which are:

Unit Testing

Broadly speaking, unit testing is a testing method where individual units of source code, program modules, usage procedures, and operating procedures are tested to determine if they are fit for use. They make sure that a section of an application, or a “unit”, is behaving as intended. Unit tests are used to test models.
Although it is possible in Rails to run all tests simultaneously, each unit test case is tested independently to isolate issues that may arise.

Unit testing finds problems early in the development cycle rather than later. It’s always better to find bugs earlier so that features that are added later in the cycle are using the correct parts. Additionally, unit testing forces developers to structure functions and objects in better ways, since poorly written code can be impossible to test.
Finally, unit testing provides living documentation of the system as it is developed. The description of the tests can give an outsider a basic understanding of the unit’s API and its features. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct.

Model Specs/RSpecs

Model specs are similar to unit tests, in that they are used to test smaller parts of the system, such as classes or methods. Sometimes they interact with the database, too. They should be fast and handle edge cases for the system under test.

MiniTests

Minitest is a testing suite for Ruby. It provides a complete suite of testing facilities supporting test-driven development (TDD), behavior-driven development (BDD), mocking, and benchmarking. It’s small, fast, and it aims to make tests clean and readable.
Minitest is the default testing suite used with Rails, so no further setup is required to get it to work. Along with RSpec, it is one of the two most commonly used testing suites used in Ruby.

I initially thought we were going to make use of Unit Tests over Mini Tests. However, It was indeed a joy and not too great a surprise when Arit (one of our senior Engineers), told us we would be creating MiniTests in few weeks to come.
MiniTest can handle both TDD and BDD syntax and comes with a bunch of testing tools to make automation easy.
There are even several extensions to customize MiniTest to your needs plus I learned it is even fairly easy to port Unit Test to MiniTest. It does have to be installed via bundler and MiniTests are often used over Unit Tests because the syntax encourages human-readable tests!

Ultimately, this process of researching testing has been very helpful. I now find it quite exciting to know that in few weeks to come I would have more knowledge on this as Arit(one of our Senior Engineers) is working on creating a video that explains, How to create MiniTests in simpler terms and details for the Team. I know it won’t be too difficult once we get fully started.
Additionally, I am also starting to have a bit of understanding in seeing its importance to maintaining well-organized and clean code which would make the development of Our Shiftwork app more resilient to bad data.
I am looking forward to exploring more facets of testing soon!

Referencing:
https://guides.rubyonrails.org/testing.html
https://en.m.wikipedia.org/wiki/Unit_testing#
https://dev.to/milandhar/unit-testing-in-rails-4oke
https://www.tutorialspoint.com/ruby-on-rails-2.1/rails-unit-testing.htm

Testing

Gabrielle Easton — Wed, 07 Apr 2021 16:55:36 +0000

Testing is very challenging for me. My Week 3 was about understanding the importance of testing and exploring various testing frameworks and approaches to test the software. I welcomed the challenge and would like to summarize my learning in today’s post.

Let's define tests. Automated tests are scripts that output whether or not your code works as intended. They
verify that the program works now and will continue to work in the future without manually testing it. Once you write a test, you should be able to reuse it for the lifetime of the code it tests. Your tests can change as expectations of your application change. Tests catch bugs sooner, preventing them from ever being deployed.

TDD vs. BDD

Test-driven development involves writing a test for a specific piece of functionality, running the test to see if it fails, and then writing the code to make the test pass.
Behavior-driven development involves a developer, QA engineer, and product manager. The group meets to come up with examples of acceptance criteria in a user story. These examples are described using a domain-specific language and put into a feature file. The feature file is converted into a specification where developers can then write an actual executable test.

Happy path vs. unhappy path

The happy paths are what users are supposed to do when using an application. The unhappy paths are many ways that users can break your software.

Testing in Rails

As we continue developing our application, Shiftwork, we will be adding tests to the Models and Controllers with MiniTest. MiniTest is a library for TDD, BDD, mocking, and benchmarking. MiniTest is a powerful yet underappreciated testing framework in the Rails community. It comes with the Rails application, so it's available right away, no need to install anything else.
MiniTest has been designed to be a small and fast testing framework. As I learn how to write tests, I will write about it from my practical perspective in my other posts.

One of the standards for developing a solid software application is writing tests early and making sure all parts of the app are tested well. Testing is an essential skill, and it's worth spending time to learn how to write well-structured tests. I accept the challenge!

Photo by Hans Reniers on Unsplash