Why these two folders exist
There is a shape a repository takes when you are learning something for the first time. It is a folder with no README beyond a title, no requirements file, no license, no CI, no tests, no issues, and a burst of commits on a single day followed by silence. I have two of these on my GitHub. One is an OpenCV sandbox from October 2022. The other is a CSES practice folder from June 2025. Both were the kind of thing I opened a browser tab for, cloned, poked at for a Tuesday night, and then quietly stopped touching. Neither has a second week.
I keep them public because that shape is honest. A project-shaped folder tells you what the person built. A learning-shaped folder tells you what a person tried to remember on a Tuesday night in the middle of coursework. I like having both.
Here is the shape lined up.
| Repo | Date | Days of commits | Files | Lines | README |
|---|---|---|---|---|---|
| Opencv-study | 2022-10-08 to 2022-10-09 | 2 | 8 Python scripts | 252 | one line |
| cses-practice | 2025-06-28 to 2025-06-29 | 2 | 4 Python scripts | 92 | none |
OpenCV, October 2022: what "study" meant
Opencv-study is eight standalone Python files committed across two evenings in October 2022. All 252 lines of it. No notebooks, no image samples, no subfolders, no requirements.txt. The filenames give away what I was doing:
rainbow paint.pymouse click circle.pydrawline to point clicked.pydraw line to point clicked canvas.pydraw line mouseover and erase with normal mouseover.pyrandom color click standard.pyrandom color box mouse over.pytext over camera.py
Spaces in the filenames, no snake_case, tabs for indentation. The commits went "Create rainbow paint" then "Rename rainbow paint to rainbow paint.py", which means I originally committed the files with no extension and had to go back and fix them. Every file is a tiny sandbox for one mouse-callback idea.
The API surface across all eight files is small. cv2.namedWindow, cv2.setMouseCallback, cv2.imshow, cv2.waitKey, cv2.destroyAllWindows. Mouse events limited to EVENT_MOUSEMOVE, EVENT_LBUTTONDOWN, EVENT_LBUTTONUP, EVENT_RBUTTONDOWN, EVENT_RBUTTONUP. Drawing primitives: cv2.line, cv2.circle, and cv2.putText with FONT_HERSHEY_SIMPLEX and LINE_AA. Canvas is a 500 by 500 white image made with np.ones([500,500,3],'uint8')*255. Colors are always (x%255, y%255, ...). Move the mouse, the pixel is a new color, that is the game.
The one file that touches a webcam is text over camera.py. It opens cv2.VideoCapture(0), reads a frame, calls cv2.putText over it, and shows the frame. That is the extent of the webcam work. I never got as far as filters, thresholding, contours, Haar cascades, or anything you might call computer vision proper. What I called "OpenCV study" turned out to be OpenCV mouse and drawing study. I did not come back the next day.
CSES, June 2025: four problems, then silence
cses-practice is smaller. Four files in an Introductory_Problems/ folder, 92 lines total, two commits. The second commit message is a single character: "1". The problems, in order:
weird_number.py, the Collatz sequencemissing_number.py, the Gauss-sum trickincreasing_array.py, greedy min-movesrepetetions.py, typoed filename, and the interesting one
The code is plain. input() and print(), no sys.stdin, no imports, no type hints. Whatever CSES was going to teach me about fast input, I was not doing it yet.
The thing I like about this repo is the docstring pattern. Every file except increasing_array.py ends with a small #Learnings and #Prevention block where I retro my own bugs. Something like:
#Learnings: Forgot to print the final 1 in the Collatz sequence.
#Prevention: Print the last element after the loop exits, always.
#Learnings: Missed handling NO SOLUTION for n=2,3.
#Prevention: Consider small n as a separate branch before writing the general case.
#Learnings: Inconsistent variable naming between a and arr.
#Prevention: Pick one name and stick to it for the whole file.I do not remember writing those blocks but I recognize the person who did. That is the shape my notebooks take. Bug then note then move on. It is the honest part of the repo.
repetetions.py is the file worth looking at twice. The filename is a typo of "repetitions", which is one CSES problem, but the code inside prints an even-then-odd sequence for n greater than or equal to 4 and NO SOLUTION otherwise. That is a solution to the CSES "Beautiful Permutation" problem, where you need to output a permutation of 1 to n with no two adjacent elements differing by exactly 1. Two problems, one typoed filename, and the solution I have is likely wrong for either. My guess is I confused two problems while flipping between the CSES tab and my editor, wrote the wrong solution to the wrong problem under a third problem's misspelled name, and never went back to fix it.
I do not know if I kept practicing CSES elsewhere. There is no second folder on my GitHub for it. If I did, it happened in a private repo or a Codeforces tab, and I have no record of it here.
What learning repos are honestly for
A learning repo is not a portfolio project and it is not a resume line. It is a log of what a Tuesday night felt like when I was trying to remember which OpenCV mouse-event constant fires on right-click, or trying to remember whether the Gauss sum is n times n plus one over two. It exists because I opened a shell and typed git init before I knew whether the thing I was starting would go anywhere. Most of them did not. That is fine, and I have stopped feeling like I need to delete them.
The green squares chart on my profile does not distinguish between a Tuesday night of eight mouse-callback files and a Tuesday night of shipping something. I have not decided whether that is the flaw in the chart or the feature.