Your First Session

Clone the repository from https://github.com/onblog/SnowJena, specifically the snowjena-ticket-server application, and set it up locally. 
First, ensure the snowjena-ticket-server application builds and runs successfully with the current setup. You don’t need to worry about other applications in the repository. 
Next, upgrade the Spring Boot version to 3.3.2 in the snowjena-ticket-server application, making only the necessary changes related to this version upgrade. 
After the upgrade, test the snowjena-ticket-server application to confirm it still builds and runs correctly. 
You don't need to push code. Instead, share a zipped folder. 
Also share a screenshot of the application running successfully in your browser.

## Overview
Given a link to a github repository, use Gource to visualise the git history.

## What’s Needed From User
- Provide a link to a github repository

## Procedure
1. Install dependencies
- Install Gource on your machine using `sudo apt install gource`
- Install `ffmpeg` and `xvfb` on the machine.
- Set up `xvfb` using `ps aux | grep Xvfb`
2. Clone the git repository locally on your machine.
- Navigate to the root directory of the Git repository.
3. Get the total days of commits -
- Get the start date of the first commit using :
 `git log --pretty='format:%cd' --date='format:%Y-%m-%d' | tail -1`
- Get the end date of the latest commit using :
 `git log --pretty='format:%cd' --date='format:%Y-%m-%d' | head -1`
- Calculate the total number of days
4. Choose the right parameters -
- Considering the default duration to be 60 seconds, calculate the speedup factor using - 60/(total number of days).
- Set the parameter `--seconds-per-day` and `--auto-skip-seconds` to the calculated speedup factor.
- Hide elements using `--hide dirnames,filenames`
- Set `<filename>` to the name of the git repository.
- Set the parameter `--output-ppm-stream` to `<filename>.ppm`
5. Run gource with all the parameters.
- Use xvfb to run gource
  `xvfb-run --auto-servernum --server-num=1 gource ...`
6. Generate a .webm file -
- Run the following command
  `ffmpeg -y -r 60 -f image2pipe -vcodec ppm -i <filename>.ppm -vcodec libvpx -b 10000K <filename>.webm`
7. Output:
- Send the video file as an attachment using the messaging interface to the browser.

## Advice and Pointers
1. Adjust the frame rate and resolution to balance video quality and file size.
2. There is no need to authenticate the GitHub CLI on the machine.
3. Make sure the .ppm file is properly generated for all the commits.

## Overview
The task is to make a quick pull request to a repository.
Since this is a 'quick' PR, you will not need to run any code or test anything; simply make a PR and the user will handle the testing. Your only responsibility is reading and writing code.

## What's Needed From User
- The repository to create a pull request to

## Procedure
### Prepare your workspace
1. Navigate to the relevant repository on your machine (clarify with the user if you can't figure it out).
    - Check out the main branch and note down the name of the main branch.
    - Checkout to a new branch since you'll be making a pull request. The name of the branch has to be of the format `devin/<your-branch-name>/X` where X is a random number. For example `devin/fix-popup/3234`. Run `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` and replace `{branch-name}` with the name of the branch you want to create.
2. Study the request, codebase, and plan out the changes
    - Review the most relevant files and code sections, identifying relevant snippets.
    - Inform the user of your plan
### Work on the PR itself
3. Make the code changes
    - Don't change anything that wasn't specifically requested by the user
4. Make the PR
    - Commit and push the changes and tell the user.
    - See advice section for the exact command to make the PR
    - Make a pull request & review the pr to make sure it looks OK.
    - Ensure all GitHub actions pass successfully & make necessary changes until they do
    - Send the PR link to the user and summarize what you changed.
5. Address any feedback from the review; send the PR link again every time you make any changes
    - If you need to make updates, just push more commits to the same branch; don't create a new one


## Task Specification
- PR link is included in your messages to the user
- PR was reviewed after creation
- PR does not include any stray changes
- PR does not change anything that wasn't specifically requested by the user
- PR description should include a summary of the changes, formatted as a checklist
- PR description should mention that the code was written without testing, and include - [ ] Test the changes as an item
- PR description should include the following footer: "This PR was written by [Devin](https://devin.ai/) :angel:"
- PR description should include any metadata that the user has provided (e.g. linear ticket tags in the appropriate syntax)
- PR description should not be malformatted (use --body-file instead of --body if the newlines are garbled!)

## Forbidden Actions
- Do NOT try to access github.com through the browser, you will not be authenticated.
- NEVER force push on branches! Prefer merging over rebasing so that you don't lose any work.
- Do NOT push directly to the main branch.

## Advice and Pointers
- Double check the name of the main branch (which could be `main` or `master`) using `git branch`.
- For repos with CI/CD on github actions, you can check build logs using the gh cli. if you're asked to fix a build/fix lint, you should start by looking at recent build logs
- Check `git status` before committing or adding files.
- Use `git diff` to see what changes you have made before committing.
- If you're updating an existing repo, use `gh cli` to make pull requests.
- Send the PR link to the user every time you update & ask them to re-review so that it's convenient for them
- You should already be authorized to access any repositories the user tells you about. If not, ask the user for access.

## Overview    
This playbook guides you through the process of creating an architectural diagram of a public GitHub repository or any source code using [C4-PlantUML](https://github.com/plantuml-stdlib/C4-PlantUML)

## What’s Needed From User
1. Provide link to your desired public github repository or a zip file containing your source code
2. Provide instructions if you want the architecture diagram to be customized

## Procedure
1. Install dependencies
    - Ensure that Java runtime is installed in your system
    - Install Graphviz using `sudo apt install graphviz`
2. Download PlantUML from the browser
    - Navigate to [https://plantuml.com/download](https://plantuml.com/download) in your browser and download [PlantUML](https://github.com/plantuml/plantuml/releases/download/v1.2024.5/plantuml-1.2024.5.jar)
    - Ensure that it is included in your PATH
3. Extract the source code (if zip file is provided)
- Download the zip file provided by the user directly to the current working directory
- Extract the source code from the zip file using `unzip <file_name.zip>` 
4. Setup the GitHub repository (if provided)
    - Clone the GitHub repository provided by the user
    - Navigate to the correct directory
5. Analyze the functionality of different components in the app carefully
    - Analyze the app directory
    - Understand the functionality of each component in the app very carefully
6. Generate the `.puml` file
    - Keep `Person` element outside `System_Boundary`
    - Make sure to add all the essential components and their relevant details in the diagram
    - Refer to [https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/README.md](https://github.com/plantuml-stdlib/C4-PlantUML/blob/master/README.md) for detailed instructions
    - Include the following in the `.puml` file after `@startuml`:
    !include  https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
    !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml
7. Generate the architecture diagram
    - Generate the architecture diagram from the `.puml` file
    - Make sure that the command is run without errors
8. Share the final deliverables
    - Share the architecture diagram with the user as an attachment

## Deliverables
1. The architecture diagram of the GitHub repository or the source code

## Advice and Pointers
1. Ensure that the diagram is clear and easy to understand

Can you do some research about Alan Turing and then make a nice website about him? 
Include a photo