Meeting #1: Project Vision and Strategy

[abenteuerzeit]

Dev Launch - Meeting Plan

We are meeting to discuss TenantTalk, a platform for renters to share their experiences, rate, and review landlords and rental properties. You can find the repo here: TenantTalk GitHub.

About

In our meeting, we will discuss the construction of TenantTalk. Efosa and I have chosen React and Redux for the front-end, Node.js and Express.js for the back-end, and MongoDB for our database. This is an early stage, and these tech decisions may change if we find a more efficient way to achieve our goals. I plan to use a RESTful API for communication between the front and back ends. You can learn more about these technologies from the following resources:

• React and Redux
• Node.js and Express

We will also discuss our working methodologies. I propose using the Twelve-Factor App methodology, a set of best practices for building software-as-a-service apps. We should discuss each of the twelve factors in our meeting. You can learn more about the Twelve-Factor App method here.

Our testing methodology will be Test-Driven Development (TDD). This means we write a test that fails before we write new functional code. The goal is to write tests that define the functionality we want to implement. Once the tests are in place, we write the code that makes those tests pass. If all tests pass, then our code meets all the defined requirements. You can learn more about TDD here.

I will reject pull requests, starting today, that do not have tests, and I'll ask you to write them. Or, you could first start by writing the tests and then pushing them first.

During our meeting, I will use Otter.ai. This is a tool that uses artificial intelligence to make real-time transcription of meeting notes. These notes are shareable, searchable, accessible, and secure. You can learn more about Otter.ai here.

I look forward to our meeting. I invite all of you to share your ideas, suggestions, and questions. More details about this meeting can be found below. Let's work together and make empowering renters a success!

Meeting Agenda:

1. Set the stage (5 min): The meeting starts off with a reminder that aiming for "good enough" rather than perfection, and keeping an open mind for discovery and innovation is desired. I don't care about perfection. We prefer to Fail fast, fail often. See: The Fail Fast Principle.
2. Introductions (10 min): Everyone introduces themselves, explains their vision for their contribution to the project, and answers the question, if all jobs had the same pay and hours, what job would you like to do? to encourage engagement and collaboration.
3. Project Overview (15 min): Adrian provides an overview of the TenantTalk project, its goals, and how it fits into the larger market context.
4. Review of Tools and Technologies (15 min): Everyone discusses the tools and technologies to be used in the project, including React, Redux, Node.js, Express, MongoDB, and RESTful API.
5. Discussion on Working Methodologies (15 min): Everyone discusses the Twelve-Factor App method and Test-Driven Development (TDD) approach that will be used in the project.
6. Introduction to Otter.ai (10 min): Adrian introduces Otter.ai, explains its purpose and how it will be used during the project meetings.
7. Roles and Responsibilities (15 min): Discuss the roles and responsibilities of each team member in the project.
8. Project Timeline and Milestones (15 min): Present the proposed project timeline and key milestones.
9. Questions and Answers (10 min): Allow time for any questions and provide answers to clarify any doubts.
10. Closing (5 min): Conclude the meeting, summarizing the key points discussed and the next steps.

Technologies

1. React and Redux: React is a popular JavaScript library for building user interfaces, especially single-page applications. It's efficient, flexible, and it comes with a rich ecosystem. Redux is used for managing the application's state. It works well with React and can handle complex state interactions predictably. I also recommend trying out Redux-Toolkit. You can learn more about these technologies here.

2. Node.js and Express: Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine, making it ideal for building fast and scalable network applications. Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications. You can learn more about these technologies here.

3. MongoDB: MongoDB is a source-available cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with optional schemas.

4. RESTful API: REST stands for Representational State Transfer. It is an architectural style for distributed hypermedia systems. It is an architectural style that defines a set of constraints to be used when creating web services.

Architecture

For the TenantTalk project, a three-tier architecture would be suitable:

1. Presentation Layer (Front-End): This is the topmost level of the application. The main purpose of this layer is to translate tasks and results to something the user can understand. This is where React and Redux come into play. React will be used to build the user interfaces, and Redux will manage the application state.

2. Application Layer (Back-End): This layer guides communications and controls application functionality by performing detailed processing. Here, Node.js and Express will be used to handle requests and responses between the client and the database.

3. Database Layer: This layer includes the data persistence mechanisms (database servers, file shares, etc.) and the data access layer that encapsulates the persistence mechanisms and exposes the data. The data access layer should provide an API to the application layer that exposes methods of managing the stored data without exposing or creating dependencies on the data storage mechanisms. MongoDB will be used for data storage.

This architecture allows for separation of concerns, making it easier to maintain and scale the application. It also allows for efficient collaboration among different teams working on the project.

Question: What are all the specific requirements and constraints of the project?

As for the current choice of architecture, it's justified by the nature of the project and the technologies used. React and Redux are well-suited for building single-page applications with a complex state, which justifies a front-end centric architecture. Node.js and Express are used for the back-end, providing a fast and scalable environment for server-side logic.

As for the architectural style, it's not strictly a monolith or microservices. It's closer to a monolith since it's a single application, but it does have some characteristics of microservices, such as the separation of concerns between the front-end and back-end. However, it doesn't have the full complexity of a microservices' architecture, which involves managing multiple independent services. Some developers call it a majestic monolith.

Front-End Division of Labor

Dividing work and views for the front-end development team is a good idea for several reasons:

1. Specialization: By dividing the work, each developer can specialize in a specific area, such as desktop view or mobile view. This allows developers to become experts in their area, leading to higher quality code.

2. Parallel Development: Work can be done in parallel, accelerating the development process. While one developer is working on the desktop view, another can be working on the mobile view.

3. Easier Maintenance: It's easier to maintain and debug the code when it's divided into smaller, more manageable pieces.

4. Better Performance: By tailoring the code for specific views, we can optimize performance. For example, the mobile view can be optimized for slower network speeds and smaller screen sizes.

The various views can be imported into a separate stylesheet for optimal responsiveness.

Serverless architecture benefits:

1. Scalability: Serverless architectures can automatically scale to accommodate traffic patterns, making them a good choice for applications with variable demand.

2. Cost Efficiency: With serverless, you only pay for the compute time you consume. There's no charge when your code is not running.

3. Reduced Operational Management: Serverless abstracts away the infrastructure, allowing developers to focus on the code rather than managing and operating servers or runtimes.

However, serverless also has some drawbacks:

1. Cold Start: A cold start happens when you execute an inactive function for the first time. It involves initializing the runtime and starting the function, which adds some latency to the execution.

2. Debugging and Monitoring: Traditional debugging and monitoring tools don't always work well with serverless architectures.

MVC

After considering the nature of the TenantTalk project and the technologies we are using, I recommend using the Model-View-Controller (MVC) architectural pattern. Here's why:

1. Simplicity: MVC is simpler than MVVM, making it easier to understand and implement. This is crucial for a project in its early stages.

2. Control: MVC gives us more control over the application's behavior, which is important for a project like TenantTalk where we need to manage complex state interactions.

3. Community and Resources: MVC has a larger community and more resources, which can be beneficial for problem-solving and learning.

4. Compatibility: MVC works well with our chosen technologies (React, Redux, Node.js, Express, MongoDB).

However, MVC also has some drawbacks:

1. Tight Coupling: In MVC, the View and Controller are tightly coupled, which can make it harder to maintain and test the application.

2. Scalability: MVC might not be as scalable as MVVM for larger applications.

I believe that MVC is a better fit for the TenantTalk project at this stage. As the project evolves, we can reassess this decision and consider other architectural patterns if necessary.

[abenteuerzeit]

Project Vision and Strategy Meeting Minutes

Date: June 11, 2023
Time: 19:00 CET
Location: Google Meets

Summary

This meeting aimed to establish the project vision and strategies for developing a platform where users can rate and review their living experiences at specific addresses. The team agreed on prioritizing functionality, embracing the fail-fast principle, and maintaining comprehensive documentation. Roles, technologies, and next steps were discussed.

Meeting Details

Attendees

Name	Role	Github
Adrian Mroz	Team Lead & Back-End Controller, Models	@abenteuerzeit
Efosa Ojomo	Front-End Developer, Views	@Efzo
Piotr Palacz	Front-End Developer, Views	@piotrpalacz
Dmytro Pishchenkov	Front-End Developer, Views	@DemetrPI
Eren Yazici	Back-End Developer - Business Logic, Models	@LucidMoments

Minutes prepared by @abenteuerzeit.

Meeting Objectives

The goal of the meeting was to define the project vision and outline key strategies for a platform that provides residential experiences at specific addresses, akin to Yelp's or Glassdoor's business model but applied to the housing market.

Key Decisions

• Meeting Documentation: The team will maintain documentation for every meeting to ensure all members can reference past decisions or discussions.
• Prioritization of Functionality: The team will adopt a "good enough" approach, prioritizing working code over perfection.
• Embracing the Fail Fast Principle: The team will foster a culture of rapid trial, error, and adjustment.
• Team Familiarization: All team members shared their interests and hobbies to foster better collaboration.
• Project Overview and Vision: The project will create a platform for users to rate and review their living experiences at specific addresses.
• Division of Labor: The team discussed their specific roles and tasks.

Action Items

• Multilingual Support: The team will implement multilingual functionality, focusing initially on English and Ukrainian.
• Internationalization in Code: The team will use React for the development framework and code it from the beginning to allow for translations.
• Technology Selection: The team will use React for the front-end, Redux or Redux Toolkit for front-end state management, and Node.js and Express.js for the backend. MongoDB is the proposed database.
• Learning Experience: The team will use the project as an opportunity to learn new technologies and tools.
• Potential Challenges and Future Technologies: The team will consider integrating additional technologies like Python for web scraping.
• Architectural Approach: The team agreed on an MVC (Model View Controller) architecture for the application.
• MongoDB Considerations: The team will continue to evaluate MongoDB or consider alternatives like PostgreSQL, MySQL, or Firebase.

Next Steps

The team agreed on a two-week timetable to implement the following features and tasks:

• Front End Division: Efosa, Piotr, and Dmytro will focus on learning Figma and creating a wireframe of the user interface.
• Back End Division: Adrian and Eren will work on the controller and routes, starting with RESTful APIs to provide mock data for the views. Adrian will start developing the controller and tests, and Eren will work on a Google scraper to gather data about residential experiences at specific addresses.

The team will meet again in two weeks to review progress and adjust plans as necessary.

Meeting Transcript

• Otter's transcription

Note: The link is restricted access; you can submit a request to be approved by Adrian after clicking the link.

Key Points

Introduction and Setting the Meeting Agenda

The attendees were made aware of the meeting's structure through the meeting agenda. There was a request for maintaining proper documentation for every meeting as a point of reference for everyone. This will ensure everyone is on the same page and can review previous decisions or discussions at any time.

1. Quality Expectations: The group agreed on a good enough approach to the work, prioritizing functionality over perfection. They preferred working code, even if it's not perfect, which can be refactored later. This philosophy encouraged them to take the first step instead of focusing too much on planning or worrying about making mistakes.

2. Fail Fast Principle: The group preferred to fail fast and fail often, a common principle in IT and startup culture. This involves pushing for rapid trial, error, and adjustment in their development process. This encourages error handling and trying new things.

3. Getting to Know Each Other: Team members shared their interests, hobbies, and what they'd like to do if there were no pay and hour constraints. This led to a better understanding of each other's personality and preferences.

Project Overview

The project aims to fill an information gap in the market regarding what it's like to live somewhere or rent from a specific landlord. The goal is to create a service where users can leave their opinions about their living experiences at a particular address, similar to how Glassdoor applies to searching for jobs. The team aims to set up the basics first, including a good-looking front page and a well-structured back-end.

1. Division of Labor: Specific roles and tasks were self-assigned during this meeting.

2. Multilingual Functionality: The team acknowledged the need for multilingual support, initially focusing on English, Polish, and Ukrainian due to a significant population of Ukrainian tenants. They decided to avoid hard-coding text into the application and instead utilize placeholders or variables for text. This approach enables future language translations by simply changing database entries, thus making the site adaptable to different user locales.

3. Internationalization in Code: The attendees considered using React for their development framework and discussed how it should be coded from the beginning to allow for translations. They also highlighted the importance of writing unit tests to ensure the front-end can display content in any language. They stressed starting with hard-coding is okay as long as the developer moves to refactoring the code so that all text is stored in a database and retrieved as needed. This approach allows for future scalability and flexibility.

Technology and Tools

The team discussed the selection of technologies and tools to be used in the project.

1. React and Redux: React was chosen for the front-end, with Redux or Redux Toolkit being considered for state management. These technologies provide efficient, flexible, and predictable ways to build user interfaces and manage application state.

2. Node.js and Express.js: Node.js was selected for theback-end, along with Express.js as the web application framework. Node.js provides a fast and scalable environment for server-side logic, while Express.js offers a minimal and flexible framework for building web and mobile applications.

3. MongoDB: MongoDB was proposed as the database for the project. It is a document-oriented NoSQL database program that provides scalability and flexibility in handling evolving data structures. The team will continue evaluating MongoDB and consider alternatives like PostgreSQL, MySQL, or Firebase based on specific project requirements.

4. RESTful API: The team plans to use a RESTful API for communication between the front-end and back-end, following the principles of Representational State Transfer (REST). This architectural style enables the development of distributed hypermedia systems with a set of constraints for building web services.

Methodology

The team discussed working methodologies to guide their development process.

Test-Driven Development (TDD)

The team agreed to adopt Test-Driven Development (TDD) as their testing methodology. With TDD, tests are written first to define the desired functionality, and then the code is written to make those tests pass. This approach ensures that the code meets the defined requirements and promotes code quality.

The Twelve-Factor App Methodology

The team discussed the Twelve-Factor App methodology, a set of best practices for building software-as-a-service applications. They will consider each of the twelve factors during their development process to ensure scalability, maintainability, and transferability of the application across different environments.

Otter.ai for Transcription and Documentation

The team was introduced to Otter.ai, an AI-powered tool for real-time transcription and meeting notes. Otter.ai will be used during project meetings to generate transcriptions that can be shared, searched, and accessed securely. This tool will facilitate documentation and provide a reference for team members who couldn't attend the meeting.

Roles and Responsibilities

During the meeting, the team discussed the roles and responsibilities of each team member in the project. Adrian encouraged self-decision in determining roles and responsibilities, allowing each member to contribute according to their strengths and interests.

Project Timeline and Milestones

The team presented a proposed project timeline and key milestones for the next two weeks. The timeline includes specific features and tasks to be implemented, such as creating wireframes, developing the front-end user interface, working on the back-end controller and routes, and gathering data through a Google scraper.

Questions and Answers

The team allocated time for questions and provided answers to clarify any doubts or address concerns.

Next Steps

The team agreed on a two-week timetable to implement the following features and tasks:

• Front End Division: Efosa, Piotr, and Dmytro will focus on learning Figma and creating a wireframe of the user interface.
• Back End Division: Adrian and Eren will work on the controller and routes, starting with RESTful APIs to provide mock data for the views. Adrian will also begin writing tests, and Eren will develop a Google scraper to gather data about residential experiences at specific addresses.

The team will meet again in two weeks to review progress, adjust plans as necessary, and discuss any challenges encountered during implementation.