Before I start this post, it’s become a thing that we writes our retros with a 3 instead of a e for the second letter. Inspired by Lewis, it is as ongoing trend for the past two retros that we had.
Today, we were quite certain on the technologies we were going to use given we had done our research yesterday:
- Mapbox (This software will allow us to intake data from APIS that Mapbox offer along with other features of a map that it will provide)
- React (This will be our front end where everything that is viewed and the outlook)
- Node(This was the software that will help us require packages or other softwares that will form our back-end logic)
- Jest (This is the main testing framework that will test our front-end, it tests any javascript code but is the basis for testing React)
- Mocha(This is a test framework that sets up and describes tests suites, things like writing “describe” in tests)
- Chai(This is a javascript library that provides assertions or a library of matchers, which allows more flexibility for us to test)
- Sinon(This is another javascript library that will enable us to stub and mock dependancies. It helps to control the effects of when we stub or mock them intact as well)
With all of this knowledge in our pockets, we concluded “We are prepared”
Before pictures of trying to understand how our technologies interact or would communicate.
Drawing out a rough diagram of how we thought everything worked resolved in a basic format. However, it was a good idea to start mapping out how all the technologies spoke to each because we came to the conclusion that we then needed Express and MongoDB.
- Express (Express is javascript library that acts like Sinatra for Ruby. It’s where our Model View Controller will happen, and especially where we will declare our routes)
- MongoDB(This acts like PSQL, a database where all our saved data will be categorised into the databases made with this technology)
In short, we were building a full on javascript library or what they call a MERN Stack program (MongoDB, Express, React and Node).
Although I was not satisfied with the diagrams, I knew once we had configured and laid out the foundation of our project, that we would be better aware about it. I made it a goal to try draw out all the code after trying to understand it today.
Note: This process is very long! I may have gotten some parts wrong or made spelling errors! If you spot them, please comment below and I’ll note it! Will appreciate the support x
The Setup Process:
Our next step, given we were about to start the project was to sit together as a four and work it all out together. We researched strategies and found answers to problems every step of the way. What was special about today was how we rotated in pairs so that everyone got a chance at coding today. It not only trained us to be patient when each of us was being driver as navigators, but also to have the confidence of being the driver in the team.
This was so we could achieve our goal of wanting “everyone to be on the same page” the whole way through.
With our mugs and laptops intensely searching. Tom’s head is behind Eva.
Overall, we managed to set everything up on the second try. A lot of the mistakes we made on our first try dictated how it should have been set up.
We first started off from the front end to the back end. I assume many of us thought to go chronologically based on the basic diagrams we made but mainly because React created a whole load of things for us. This was a good start to understand how to link the testing framework and React together (and make sure the connection was working by writing tests).
However, the mystery of then getting the back-end finished and connected to what we had just made was a misty fog we could not see through.
Thank god we dodged that bullet.
It then made sense, base on our research that we started of with express. To me, given express is like the MVC and where our routes would be, it was the connector for both front and back end technologies. As if it was like a very important bridge or passage way data would pass through.
From then, we could assemble the front end which was React. Then, we could connect the back-end which was MONGO DB. Finally, we added the testing framework given we had a solid foundation that needed the armour of testing, to prove that our project had a stronger code base. It made sense to do this way because once we had the foundation, we could have our testing framework over the basis of both front and back.
Plus, it thought us that whilst we were experimenting with the connection of the front to back, that we would have to mock our fetch method when we get data from the API. I didn’t explain before but the only way we could test the connection between all these technologies was to write sample code base on tutorials or data.
So if you are wondering what is next, yes, given I want to better my basic diagram of how everything connects…I’m going to write a summary of how we setup the foundation of our project, otherwise a MERN stack project.
Our way of setting up a MERN Project:
Wished it was as short as when you watched how the power rangers transformed, but hey, this is what it’s like
- Create a repository on Github (to start off with the project, so you can commit or go back in your steps). Let’s install the connector, Express.
Installing Express.
- Install Express given it’s the connector to the front
npm install -g express-generator
- Then, you create the back-end framework. You have to give it a name after you call express
express map-app-backend
- Go into React-backend/routes/users file in the project. Here, we had followed a tutorial which is linked below to prove there is a connection. We did this by hardcoding in the data of the route, so we could call something onto the page.
Create React App with an Express Backend_If you haven't heard of it yet, Create React App is an awesome way to get started with React. It creates a project…_daveceddia.com
Your router file should/could look like this:
See how we’ve hardcoded in the data
Then, now we can run the project by writing the following code.
PORT=3001 node bin/www
There is a file called www in the bin folder, which we will load alongside with the specific port and node. As we kept trying to insert this code every time we ran it, we realised you could set the default port in the bin/www file instead.
Now you can write this:
node bin/www
We wanted to have a different port so that one could look at the API data on a server whilst the other could look at our website for example, or be used for other activities (such as running mongodb and mongoose later on). By doing this setup and running the server, this made sure that Express was installed.
Great. Given we have installed the connector, let’s now get the front-end going. In other words, React.
We create the React app
create-react-app client && cd client
Here, we called it client as when we were diagramming out requests and responds between the server and client, the client referred to as the browser. Otherwise, what we saw on screen. Now, if we run this in the client folder.
npm start
This should show the default React page that you get with React.
In APP.JS, you want to create an example to prove the connection between Express and React. Given we had a routes file called users.js which some data, let’s try and print that data out.
Note: You have to be in the client folder if you want to do anything with React, including to run it. So in our client/App.js
We’ve set the state of the users to an empty array. We call the link where we could see the api User data we created in our routes(when we ran express). Convert it to json, and putting this data into the empty User array stated above. We then simply want to print the id and name of the user on the page.
Now, if we run REACT in the client folder as such:
npm start
We should then see our data of the users printed out with bullet points given its a list. This shows that Express and React are connected. Great.
Our program now has the top-half or arms and shoulders, but has no legs. We now need to connect the back end. Setting up Mongo.
This is where we setup our database technology, otherwise as the back end. You can install the package in any file anywhere given it’s local. However, let’s update our HomeBrew to the latest version.
brew update
Then, let’s simply install it!
brew install MongoDB
Although you have installed the database technology, it needs a location on your mac in a specific file and you need to change the permission so that you can use it. If you run “mongodb” now, you’ll get some weird error saying
“/data/db not found” ~ somewhere.
So what we want to do is solve this by changing directories.
cd ~
This will bring us to the right file (yes I have to figure out what this means) and then we run the following code to set the location and change the permission.
sudo mdkir -p /data/db
This sets the location of where the databases will be.
sudo chown `id -u` /data/db
This then changes the permission of the owner, that allows us to access it anywhere. Great, now that error should not be there. Let’s change back into our project, in my case it’s called map-app
cd map-app
To run mongo (to see whether your setup has worked), run mongod on one server and then mongo on the other as such .
mongod
To run mongod or mongo, you do these following commands.
mongo
If not, you get this error:“should be waiting for connection that has connected database. We await for port means we can go to this cloud database”
So, with mongod running in one server, open up another tab in your terminal and run mongo. This should allow you to access and work with Mongo now, and think about it like PSQL where you run commands to check your databases.
Some basic Mongo stuff.
Let’s check what databases we have locally. We shouldn’t have any given we haven’t done anything.
show dbs
Let’s create a database. If this database exist it won’t create it. s
use map-app
Let’s check if we see the database
use map-app
We should have “map-app” listed as a result. Let’’s save a table. In this case, we are going to do a table similar to our users where we have an id and name. Mongodb can take an array which is great, but we do it as such:
db.users.save[ {( id: 1, name: “eva"}, {( id: 2, name: "lewis")} )]
Once we save, it let’s print all the data out by doing as such:
db.users.find()
The result should be that whatever data you had input, should print on the screen. Great, so now we know the database exist.
[We did a trial in the IRB version of javascript in Node. However we implemented it after we saw that it works. A good shout]
First install mongoose, which will help us with the connection of our database to our back-end of Express.
npm install -S mongoose
Now, let’s set the connection of the database with express.
Remember! This is in the app.js in the back end of express! Get out of the client folder
Let’s now create a Schema.
A schema is a layout of what data goes into the database when we create the table. This schema is named similar to the file in routes so (users.js) but in the model folder which you would have to create.
Here, you require mongoose. Then you pass in the Schema, with the following details. Then you export the Schema. This is a short summary of how it all works. Before we test whether our data is being printed on screen, let’s install one thing that will help support us.
npm install -g nodemon
Nodemon is like shotgun, where we no longer have to run the code to every change we make on our website. now if we run…
nodemon app.js
This allows us to make a change and not have to reload it.
Now, this is where it gets a bit fuzzy but we followed the tutorial below to connect our mongo to our Express. We did it in IRB to begin with, so implementing it in our actual code was way tougher. Tougher for me to explain but follow the link below. It’s a whole series of trying to set it up.
However, in short, this was the following steps we did:
- getting stuff via id in the app.js
- Adding a get request for /users/usersID
- find via the key value pair in /users/usersID
By testing the routes and loading it up on the server, this allowed us to see whether the connections were established. Although it was not part of the project, it was a good indication of whether everything was talking to each other. Very important key.
Finally, let’s solidify this project with some testing frameworks.
Let’s conclude what we’ve done so far. Right now, we’ve set up Express (Node), React and MongoDB. A three linear chain of how code talk to each other. However, this is not one project.
In fact, the front-end is it’s own project and the back-end is its own project. Yes, we are dealing with two projects in one folder, having the front-end (the client folder) nested in the back-end. Crazy stuff, go for a walk if you have to.
Hence, having two projects, each of them have a package.json file and different packages needed. In other words, we’re going to be setting up similar but different frameworks for testing in each one. The ways we’ve chosen to do it is the following
Front-End — Testing framework is Mocha, Chai, Sinon and Jest. We need to mock the request from the Mapbox Api which is why we need Sinon and Jest, for testing React
Back-End — Testing framework is Mocha and Chai, as we are simply feature testing the routes for now.
Installing the Front-end testing framework:
Change into the client folder to make sure we are installing the packages. We want to install enzyme, given React comes with the testing framework, Jest.
npm install --save-dev enzyme-adapter-react-16
Then, we want to install chai, but chai in relation to enzyme, we need a beta version. This is because REACT 16 can’t run on chai yet.
npm install --save-dev chai-enzyme@beta
Then, we want to install sinon and sinon chai to make sure our sinon framework can have a relation when we’re stubbing or mocking with testing later on.
npm install --save-dev sinon sinon-chai
We then create a setupTests.js file in the source folder and importing our testing frameworks. This is just for enzyme, and when we run the npm test, this is the file that runs first before any others.
Although one was suppose to put the import of all of our frameworks before it adapts to our project, we failed to get it working for the test so as of right now, we’ve just extracted enzyme.
In app.js, you then have to require the testing framework so that can find the files to test on. This is once you have created an app.test.js file where you’ve required the frameworks and want to extract with code file you are testing
Run NPM test in the client folder, and make sure the port is not the same as the port that is running mongoDB.
npm test
That should run somewhat sort of a test. Be careful with exporting and requiring files as we got our knickers in a twist trying to understand. Don’t worry, we didn’t get through it the first time.
If not, you can follow my team-mate Tom for more instructions! On his repo, there’s a set of instructions to how to setup these testing frameworks. This is his wise words which helped us out quite a bit.
tmerrr/mocha-enzyme-chai_mocha-enzyme-chai - Repo to play with Enzyme, Mocha, and Chai test libraries with React_github.com
Installing the Back-end framework:
For the back, we just installed mocha and chai normally.
npm install --global mocha
Don’t forget to save it as a dependency
npm install --save-dev mocha
Same for chai, which is quite straight forward given we are downloading them directly.
npm install chai
Save it as a dependency!
npm install --save-dev chai
We also installed chai-http to deal with testing http requests
npm install chai-http
And there you have it!
Fully formed and fledged!
Your testing framework for the back end if you are using just these technologies should be set up! It would be a good idea to write a test of 2+2 = 4 to see if it outputs as pass, or if you are a keen-ster for your code, write a test for your code!
Mocha - the fun, simple, flexible JavaScript test framework_Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing…_mochajs.org
Assert - Chai_Chai is a BDD / TDD assertion library for [node](http://nodejs.org) and the browser that can be delightfully paired…_chaijs.com
Conclusion:
I believe the way we approached and tackled the setup process was efficient as a team. We all had the priority to make sure we were looking out for each other and that everyone understood the code and process of what was happening every step of the way.
However, the only way to confirm that was by having a retro! I led the retro today given that I wanted an insight of my teammates’s perspective on how the process went for them and how they would do this.
Learning from previous experience being in groups, I took an exercise to ask out of a scale of 1 to 10, how the day went and what could have been done to make the day a 10. It seemed most of us were on the positive levels.
A lot of us were really happy with how we all got to code, how we all were in the process together, supported each when one didn’t know stuff and that we accomplished a challenge of setting up and getting our feet around the project. Our concerns were that we wish we could get familiar with stuff (this was quite a tricky point to discuss given it was about time and experience with the code which could come later on).
One of my concerns as I wanted to put it out there is to improve the sense of “equality” in the team. Although I felt our team vibes were good, I wanted to clarify that we should not be apologising for mistakes we didn’t commit or to belittle ourselves went we don’t feel as good. In my eyes, I hope the way I said it was to remind the team that we all were equals who brought in different skills. This was said as a “if I had to really improve my day of the process”
From a retro, we immediately went into a stand up. This was because we wanted to discuss what everyone was doing tomorrow and the goal. Main goal was to get our MVP up which contained four specific points
- User can see a rendered map on the page
- User can pin a location
- User can save a location
- User can reload the pin with the map
Sounds simple but when one has to integrate Mapbox with React, extract the data from the api and put it in the database. Then, also has to make sure you could do it the other way, is not as simple as it seems.
We decided to divide up to pairs, one dealing with the front-end and back-end of the MVP for better efficiency. Given we did this retro at 4pm, we started working off in our pairs to explore the tasks that had been given to us in the image below.
Overall, it was a great day setting up with my team mates. It was productive and progressive in our understanding, and the pace was well necessary to let the ways of how all these new technologies sink in.
Yes, a productive team
Fun fact of the day:
For those of you who don’t believe in fortunes or get fortune cookies on your final project weeks, I wouldn’t be so sure to just throw them away or ignore them. Sometimes, the wise advice you might get may not hit you till later on in the project. Or sometimes, they might coincidentally be hinting at things about your project…
For instance, my nerves were getting to me today given other groups were way ahead with user stories compared to us setting up. However, getting “progress always involves risk” calmed me down and thought about the situations clearer.
Or another instance, having “a good name is better than riches” highlighted to me that it’s the foundation of what we do compared to the amount of what we do. Quality over quantity, in terms of our understanding and proper code.
I could go on with the other two, but you already can see that it’s either related to our project metaphorically or literally :)