DEV Community: Gabrielle Easton

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

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.

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

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

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

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

Rails power

Gabrielle Easton — Fri, 26 Mar 2021 18:18:29 +0000

I am impressed with what Rails can do with one command. The challenge comes with understanding what happens under the hood.

This week I tried to understand what files and functionality were created after I ran the command Scaffold. Scaffolding in Ruby on Rails refers to the automatic generation of a simple set of a model, views, and controller, usually for a single table.

Here is the command I ran:

bin/rails generate scaffold Shift shift_status:boolean role_name:string shift_start:datetime shift_end:datetime shift_pay:integer

It created not only the model, views, and the controller, but also created test files for the models and views, a helper file for the shifts, sass files for styling, and even a ‘shifts’ resource in the routes file, which defines all possible routes for our shifts.

We can take a quick look at the routes created for us using resources by running the rails routes command.

Here is the view we are getting if we follow localhost:3000/shifts

The next step will be to add logic to controllers and association between other data(tables) in our application.

Lastly, I'd like to say a big THANK YOU to Arit, our senior engineer. I feel very supported and motivated to learn. Thank you for creating a welcoming and supportive environment.❤️

Thanks for reading!

Photo by Lopez Robin on Unsplash

Rails Application: Planning and Implementation

Gabrielle Easton — Thu, 18 Mar 2021 15:18:10 +0000

Hi there! Here I am again writing about my learnings this past week.

We started the Sprint meeting with a recap of the previous week. We shared what went well and what could've gone better. We agreed as a team that we did superbly with communicating and splitting the tasks. We were there for each other, supporting and not blocking each other issues. 🥳

In reviewing of what could've gone better, we made a list of points that need to be clarified:

Moving from Issues to Implementation (agreed on proper label use)
Wireframes/Design ideas (how detailed we'd like to be)
Speed of Development Process (doing well)
Slack vs. GitHub discussions (link the discussions when necessary)

Then we moved to Planning part. Next week will be mostly about running migrations and generating models, views, and controllers. Let's briefly go over that.

What is Rails about? Rails is designed to make programming web applications easier by making assumptions about what every developer needs to get started, allowing you to write less code while accomplishing more than many other languages and frameworks.

Rails is opinionated software. It assumes that there is a "best" way to do things, and it's designed to encourage that way by having STRONG conventions. Coders tend to find this strict adherence to conventions either very helpful or very frustrating.

Rails is built around the concept of Model - View - Controller (MVC) Architecture. MVC is a pattern for the architecture of a software application. It separates an application into the following components:

Models for handling data and logic
Controllers for handling back-end application logic (requests and responses)
Views for handling the user interface objects and front-end logic

This separation results in user requests being processed as follows:

The browser (on the client) sends a request to a page to the controller on the server.
The controller retrieves the data it needs from the model in order to respond to the request.
The controller gives the retrieved data to the view.
The view is rendered and sent back to the client for the browser to display.

Separating a software application into these three distinct components is a good idea for several reasons, including improved scalability, ease of maintenance, reusability.

Rails can either be built with views or built as a pure API without views (in which case the views would be handled by a separate front-end application, like a React app). It's still part of our discussion whether we should use React or Rails with views.

This week's task was to generate the Shifts table model, and for that, I used a Scaffold command. The Scaffold in Rails is a full set of model, database migration for that model, a controller to manipulate it, views to view and manipulate the data, and a test suite for each of the above.

I also researched how to add Bootstrap to the Rails application and apparently, there are two ways of doing that. One is using ruby gem and another is using yarn.

There is no week without GitHub learning when you collaborate with others. This week we set a guideline for branch's names.
It will help us to stay on point when it comes to reviewing each other work and approving pull requests.😁

Looking forward to more learning!

Thank you for reading!

Referencing https://www.sitepoint.com/model-view-controller-mvc-architecture-rails/
https://guides.rubyonrails.org/command_line.html
Photo by Markus Winkler on Unsplash

CodeCollab Fellowship

Gabrielle Easton — Mon, 08 Mar 2021 23:07:54 +0000

Hi, DEV community!

I would like to share my learning journey throughout the CodeCollab track organized by Our Time For Tech, a nonprofit online program that empowers early-career and career-changing Women in Tech! I am very grateful to be a part of it and have an opportunity to gain real-world, technical experience building software as part of a team.

During the next three months, we, a team of five early-career developers, will be building a complex web-application with the guidance of two senior engineers. The stack for our application will be Rails, React, Postgresql and Bootstrap.

Last week we started to prepare for the start of the CodeCollab program, we were challenged to set our local environment and create our first issues, and assign them to the project board on GitHub. GitHub's project board is a new tool I discovered. I like how easy it is to see what the team is working on and how easily it is to distribute the tasks. I also learned how to link the pull request to its particular issue.

We are learning to work as a team and to update each other progress, and timely solve problems.

The App, ShiftWork's business requirements, were discussed
on our first Sprint planning. ShiftWork will serve as an online meeting place for shiftwork-type businesses(ex: restaurants) and those who work as shift-workers (ex: servers). Businesses can post upcoming shifts. Workers can seek available shifts that need to be filled. Senior developers pointed out that at this stage it's important do not think about the implementation, not yet. It's important to focus on business and user needs and draw the MVP.

By the end of the meeting, we planned out what data will be stored in our database and the relationships between that data. We left the meeting to plan further discussion and create the issues for the following week. We agreed to create five issues that cover the creation of Businesses, Workers, Shifts, Slots, Users tables, and their attributes.

Thanks for reading! I will keep you updated on my CodeCollab learning journey.

Check out Our Time For Tech: https://ourtimefortech.org/

Photo by You X Ventures on Unsplash