2. Project management¶

This week I worked on getting set up and started with Git.

Nueval Checklist¶

Using Git and Making a Website¶

I had never really had much experience with Git at all until mid-way through 2018. I started on GitHub and had my own private repo that I could blow up as much as I wanted, but now I face a new challenge. How do I use GitLab and how do I do it respectfully? Respectfully meaning not doing the same thing my dad did in 2017 by shutting down the entire repo, but we’ll go into that later. Since I’m new to all of this, I’ll have to tread more cautiously to make sure I don’t disrupt other people working around me.

I listened to Fiore and Neil’s lectures back in 2019 on Git and Markdown. I thought that Markdown was a lot easier to use than Sublime and Dreamweaver. I decided on Markdown and I gave my reasons why on each in the respective sections below. Right now, I am using the template that Fiore made for all FabAcademy students. I had to set up a .yml file and edit a couple things so I would get the template he made pubslished and ready to work on. The yml file is called .gitlab-ci.yml and can be found in every repo.

As for using terminal and Git, I really only used it as a way to get a back up of my files. I still have it below with my Git Cheat Sheet.

Markdown¶

Markdown is a light markup language that uses a plain text formating system. It was made by John Gruber and only supports HTML as of now. I prefer it to regular HTML. HTML was always so messy looking to me (although it produces very nice looking websites) and it’s hard for me to wrap my head around. Markdown seemingly makes everything just a bit easier for me by putting all the style stuff in the .yml file and making it much more readable for people. Although .yml files are not specifically Markdown, they are very useful to use in this case. Here’s an awesome cheat-sheet for Markdown that I found! Insteading of memorizing everything, you can come back to this page and get a bit of help!

Terminal¶

Terminal was probably one of the trickiest parts of using Git. I’ve never been that good at terminal (to me, everything just moves either way to fast or drags on for forever), so I guess this is the right time to start getting good at it! I used my dad’s site to get a few cheat codes for terminal to help build my own terminal tutorial.

Sublime¶

Sublime is pretty neat! I downloaded Sublime through this link and used it on my Mac. I like Sublime because it works well with Markdown, has a nice color scheme (yes, I value aesthetics a lot. Why use something that doesn’t look good?), and an easy to follow layout. Sublime catches some mistakes that I usually make and fix them up for me real quick. Overall, Sublime is an easy to use GUI that saves time, and of course, looks pretty awesome too.

Dreamweaver¶

I used Dreamweaver a lot when I was first starting Git, but it put a lot of random junk that ended up just messing up my code even more. Since Dreamweaver doesn’t work with Markdown, I will not be wasting my time with it.

Resizing Photos¶

Resizing photos is something that you need to do in order to keep your repo’s size low. I resize my images to a width of about 800 pixels and let the height change in proportion to that. This helps decrease the amount of KB that go into it, therefore making my pictures easier to see and save space in my repo. I made a seperate folder for images that needed to be resized and then after resizing them, I pushed them to my git. To resize photos, you need to click on the photo until it pops up, then go to tools. In tools there should be a setting that says adjust size. Adjust your photos size to whatever you need. I usually do 1000 pixel width and keep all of my images at around 80 kb. If resizing to 1000 pixel length doesn’t keep it under 80 kb, then you have to switch from a .png (the file the iOS saves screenshots as) to a .jpeg (an easier, lower quality picture.) To export your photos as .jpg, go to file ‘export’ and select to convert to .JPEG. Set the quality to around somewhere in the middle (you can usually see how many kb it when using the scroller). Then you move it to your local repo, push it, and you are done!

Screen Capture¶

download quicktime
download soundflower add-on
run quicktime
select your window of interest (like cropping what you want to record)
select options: do you want a microphone, where you want to save, if you want a timer, etc.
press enter to start recording
end recording– download the file
rename file to something you will remember
upload that movie to vimeo (like below)

Vimeo¶

videos are too large to put on repo
film a video on iphone
send it to myself on email
open it on my laptop
download it to my computer
rename to something you will remember
open vimeo webpage
click profile
click upload video
select the video i downloaded
wait a couple minutes for it to load
publish
visit the page where it is
grab the link from ‘share’ options
copy the link
in the page, write [write here is the link in here]{remove this part}(and paste your link in here)
publish page and wham there it is

My Repo¶

I am so glad to be one of the people who does not have to back up and reset their repo, but I have already used up a significant amount of storage. Around 3% was already wasted on week 1 and thats about 3% too much. At the time, I did not realize the importance of resizing photos so I just added them to the repo and added them in. Since I was used to my own private repo, I may have blown through some of my own storage. Oh well, atleast I know what not to do anymore!

Uploading Files¶

So there are two ways to upload files. You can use terminal or you can manually enter them. I like manually entering them just because I know that when I push nothing is going to be copied twice. This is how some people will overload their repo because they push too many times and their files end up exploding. While I don’t use terminal much, here is the cheat sheet I have along with screenshots of every step.

Git Cheat Sheet¶

ls

** cd Documents

cd fabacademy-2020

cd brigette-oneill

git status

git pull

Below, you will see a bunch of green text. These are all files that haven’t been touched and do not need to be added to the repo again!

*Edit your desired file here. I did my index file as an example.

git status (you will have file names that are in red. that means you have editted and want to push them.)

git add /docs/about/index.md (make sure you have where each image is located)

git add (any other file you may have editted)

git status (it will show up clear! no red file names should appear)

git commit -m “updating my index file”

git push

It will then ask for your username and password. I use my email for my username. Once you are done, you will be able to see the changes on the page that you editted like I did on my about me page.

Making My Website¶

Overall, making a website (specifcally for FabAcademy) is pretty hard. You have to document every single bit of information the second you get it. If you don’t, it can slip right out of your fingers. Making a website is all about time management and staying focused. I learned that the hard way and whoever is reading this looking for insight probably will too. Every website will tell you to work ahead and to not get left behind, but if you have a busy schedule like me, it’ll most definetly happen. My advice for you is to not beat yourself up about falling behind. Use spiral development to your favor and go back to your earlier webpages. Since those are the ones that get you into global review, make sure they’re nice and detailed. If your files are too big, put a tiny place marker saying that the files are too big and you don’t want to blow up your repo. From what I’ve learned, FabAcademy is not a linear path, nor is fabrication. You’ll always find little niches whenever you’re doing a project and find something that you never really paid much attention to before. Thats noteworthy. Your files just show that you did something (that could be something super cool too!), but your observations and failures and any snafus you might find along the way are going to make your website unique.

Version Control Protocols¶

Git is a version control protocol that uses four other protocols. These include Local (files on a hard drive), HTTP (web browser), SSH (pulling and pushing through command line), and GIT (the actually repository and task manager where you can read files.)

Local: Uploading files from local is really hard and I don’t really recommend it (especially on Mac). I get lost when doing bash and don’t really like having to go through the pain of uploading and downloading everything. I understand the appeal to it when uploading images (can get them all done in one clean swoop) and by pulling you can take your own copy of your site and still work on it offline.

HTTP: I really like using the HTTP file because I think its the easiest to write on. It is a lot more tedious uploading files and you cannot work offline, but I really like the set up and aesthetic of GitLab web portal. It is easier for me to convey my thoughts through words here.

SSH: This is necessary if you do command line. You will need to set up a key and will probably spend a couple minutes figuring out everything, but it is very secure and keeps your page safe!

GIT: I like git as a task force manager and the different proponents that allow group communication and solo work. Quick and easy to move in and out of.