Compare commits

...

11 Commits

Author SHA1 Message Date
9125b73399 Loose coupling blog post 2025-02-05 22:03:48 +00:00
22ccf75c85 fix: title 2024-11-28 16:29:13 +00:00
714c6ee899 link 2024-11-28 16:28:06 +00:00
5e7f87f1a0 feat: advent of code 2024-11-28 16:26:45 +00:00
1d621666fb feat: real time trading system 2024-11-28 16:24:05 +00:00
53a848726f feat: advent of code post 2024-11-28 12:11:07 +00:00
0501d7ac9b feat: moving out blog post 2024-11-18 22:42:37 +00:00
b1dd4c7781 fix 2024-06-16 23:33:03 +01:00
742c96ad83 fix 2024-06-16 23:31:36 +01:00
af2358ac05 Merge branch 'main' of github.com:JohnCosta27/JohnTech 2024-06-16 12:19:08 +01:00
182ac1a438 feat(sedated): blog post 2024-06-02 19:45:00 +01:00
17 changed files with 368 additions and 4 deletions

1
_index.md Symbolic link
View File

@ -0,0 +1 @@
content/_index.md

View File

@ -109,7 +109,7 @@ I've talked about the book as a whole and the key lessons I have taken from it (
## [Obsidian](https://obsidian.md)
This is the champion of the entire system. I use other tools but this contains most information.
![[Pasted image 20240616115501.png]]
![Obsidian Menu](/obsidian_menu.png)
There are two reasons why I choose Obsidian, not only as the best option, but in many ways _the only option_.
@ -133,13 +133,13 @@ Here are some that I use.
A really powerful thing you can do with Dataview, is bringing tasks from across various files.
![[Pasted image 20240616120232.png]]
![Tasks](/tasks.png)
This alone means that I no longer need a todo app or a project manager, because this is plenty for me.
Mapview is also really useful so I can store all the places I have been to, and check what I thought about them. Here is an example from a recent trip to Barcelona.
![[Pasted image 20240616120358.png]]
![Map](/map.png)
## [Raindrop](https://raindrop.io)
@ -174,4 +174,4 @@ Forte is a very good writer, with many practical chapters focused directly at ge
I highly recommend you read it yourself, even if you skip a bunch of chapter to just look at CODE, this is the best resource to learn about it.
Rating: 8/10.
Rating: 8/10. e

View File

@ -0,0 +1,71 @@
+++
title = "Moving Out"
tags = []
date = "2024-11-18"
author = "John Costa"
toc = true
+++
On the 29th of October 2024, after 7 months, I finally moved into the apartment that me and my girlfriend [[Rio]] bought. This is the first time that me or her have lived on our own.
I'd like to talk about my experience, how it affected me, what went well, what went wrong, and how I'm doing after 3 weeks. And how Woking is treating me.
# The Process
As anyone experienced with buying flats in the UK, then you know the process takes a very long time, and 7 months is somewhat normal. I won't get into too many details, but there is a lot of paperwork needed, from a lot of different people.
This challenged me a lot mentally. I found myself in limbo, unsure of when I would get out. I really enjoyed living with my mum, and I can't complain about my time at home. I was treated with respect as an adult, which I thank my mum and her partner for massively. Nevertheless, the mental strain on not knowing when the buying process would finalise and when me and Rio would move in, was though. I started seeing a therapist to help with this and other aspects of my life, I did so for about 5 months, and I recommend anyone who is struggling mentally to seek help if help is available, luckily I didn't have serious problems, but I was still able to work through them, and now feel better equipped to deal with various wonders of life.
Limbo wasn't the only feeling however. Pressure was a big one too.
As readers know, buying property requires a mortgage and a deposit. This deposit in my case was 10% of the total value. I've been fortunate in life and I've work since I was 16. I worked throughout my entire time at university, through tutoring and software projects, and the internship at Decipad in my third year. \[As I side note, I feel extremely grateful to all the opportunities presented to me, and I'm quite proud of myself for all that work, it wasn't easy at times, but it paid off (this sounds really vain, I really don't mean it that way).\]
I have also worked full-time at Decipad since I graduated in May 2023, which again, helped me save the required money for the down deposit, legal costs, and moving in costs (furniture, and stuff like that).
This is by far the biggest financial decision I've made in my life, and it comes with pressure. It is something I've wanted to do, and have had in my head for quite sometime, which helps. But the pressure is still there (even today). I have a mortgage now.
# Moving In
We exchanged on a Thursday (24/10/2024) and completed on Tuesday (29/10/2024), leaving the weekend to pack. Me and Rio did so and on Tuesday, we hired a van. Which we used to pick up a sofa we had bought at the weekend, and grab the stuff from mine and her house.
Around midday we went to the estate agent to actually pickup the keys, and go to the flat for the first time in 7 months. Going in is quite a surreal feeling, but a very happy one.
Took us the whole afternoon, but we managed to move everything in. And we've been slowly unpacking ever since.
# Living alone (together)
Usually people say it's a shock, I don't feel it that way. I was quite used to cooking, cleaning and maintaining (at least part) of a home, so doing chores and keeping the place tidy, cooking meals has been one of the easier parts of the whole process. I find it pleasant (especially cooking), there's something freeing about things not being done if you (or Rio) don't do them.
## Living with a partner
This has been the best part. Me and Rio have been together since we were both 16, so around 7 years, and we click, and we continue to click once we moved in. There are certain aspects that took some communication, we're different human beings after all, but I feel like we're quite open about preferences and dislikes about the apartment.
It's not perfect, but no two people living in the same place are. But I'm very happy with how we're doing.
# Working (in Woking)
I work remotely the majority of my time (I sometimes go into our London office, which I'll talk about below), and we specifically bought a 2 bedroom apartment so one of the bedrooms would become an office. We have two desks side by side, one for me and one for Rio.
I get the most use out of this room since I'm the one who works from home, and it's really n upgrade. I used to work in the same place I slept, which worked fine and carried me through university, but since I started working full-time, slowly I've been feeling worst and worst about my work situation. It was very hard to focus, and painful to disconnect. A dedicated room for work (or some leisure, video games mostly), is really great.
# Woking
I love this town. It feels busy without being overly busy. Almost everything I'd like is close by (looking at you Waterstones), and within walking distance. The parks, the people and the shops are all great, it's a great place to live.
Another reason I choose Woking is because it is a 25 minute train away from London. And I am 5 minutes away from the train station.
There isn't much else to say, I just really like this town.
# What I'd like to do better
It is still early days, so I won't beat myself up too much about these, but there are some points I'd like to improve upon.
1. Work after work, continue to build personal projects, do coding puzzles. Don't fall into the trap of working, eating, sleeping repeat. Go to conferences, etc...
2. Exercise. I have started on this point, but it is one I really want to get better at, I want to continue with Judo, and become good and physically fit.
That's it so far. I'm sure I'll come up with more but those are the two points I really want to focus on.
# Conclusion
I moved out to Woking, to an apartment me and Rio (my partner) bought together. And we're both enjoying it a lot, the process has been difficult, expensive and stressful. But we are here, and the more interesting project starts, settling in, and developing ourselves as people, and as a couple.
There are many things I want to do, and it very much feels like the end of an era, and the beginning of the next one.
I'd like to thank a few people.
- Rio, you have been nothing but amazing in everything. You're the best partner I could ever ask for, and I'm truly grateful for you. I hope that we continue to bring out the best in each other, and live out the rest of our lives together.
- Mum, you've provided for me for 22 years. It is because of your solid foundations that I was able to push myself through school, college and then university. I couldn't even begin to work hard if it wasn't for your extreme effort to give me these opportunities.
- Stephen, Mum did most of the work but I'm not sure the last stretch would be possible without you. I lived at home all my time at university, and you helped provide a stable environment for me, where I got the grades and my first real job. Much of my professional and personal development is down to your help.
There are many more people that have helped me, so in no order here are the rest: Marcos, Henri, Marne, Mat, and the countless others. Thank you to all of you and every friend and family member I haven't listen, you are all important.

View File

@ -0,0 +1,109 @@
+++
title = "The importance of loose coupling"
tags = ["software"]
date = "2025-02-05"
author = "John Costa"
toc = true
+++
Recently at work, I was faced with creating a system that needed to integrate between two very big modules of code. These two modules are practically our entire product at [Decipad](https://decipad.com). And when you have to integrate such big parts of code, it might be tempting to do it, and test by running the server and click around in the browser (in this case, our product is a web app).
However, I didn't want to continue this pattern (we had some code that integrated these two systems, but in a heavily coupled way), and therefore I set about with a slightly different approach, and when I was done I had a much greater appreciation for interfaces (and higher order functions).
## The Problem
I need to pass information from one module (the `Editor`), to another (the `Computer`). I also need to keep some state, and do some comparisons.
Let me illustrate what I wanted to achieve by writing some pseudocode, in a non-testable way.
```ts
const setup = (computer: Computer, editor: Editor): void => {
editor.on('some-event', (e) => {
const proccessedEvent = processEvent(e); // Some function
computer.push({ ...somethingComplicated, x: processedEvent });
});
}
```
If I wanted to test this part of code, I would have to create an instance of both of these two modules. This isn't the easiest approach, because the integration I needed would have to do some pretty heavy setup for tests, which would mean the test would mostly be boilerplate, not to mention unpredictable, as these two parts of code come with a huge amount of potentially buggy code.
This is a simple enough function - and at first - it is tempting to just wire it together and move on, however, in my case I also needed to keep track of some state to avoid pushing to the computer too often.
```ts
const setup = (computer: Computer, editor: Editor): void => {
const state = new Map<string, Event>();
editor.on('some-event', (e) => {
const proccessedEvent = processEvent(e); // Some function
const existingEvent = state.get(e.id);
if (someComparison(existingEvent, e)) {
computer.push({ ...somethingComplicated, x: processedEvent });
state.set(e.id, e);
}
});
}
```
This function still looks fairly innocent, but you can see the growing complexity. In order to test in isolation that my state mechanism works, I would need to setup an entire editor, an entire computer and then I would have to use this event system through the editor in order to test my function. This might be OK in an integration test where you want to test groups of systems, but as a unit test to test the individual logic of this function, it isn't ideal.
## Only use what you need
I don't want to pass the whole computer and the whole editor to this function. Instead a better approach that would allow me to test this in a much better way, is to instead pass an event emitted (or some other interface), and instead of the computer, I could pass a higher order function. This way I no longer need an editor or a computer to test this code.
```ts
const setup = (onEventChange: (e: Event) => void, eventEmitter: EventEmitter) => {
const state = new Map<string, Event>();
eventEmitter((e) => {
const proccessedEvent = processEvent(e); // Some function
const existingEvent = state.get(e.id);
if (someComparison(existingEvent, e)) {
onEventChange(e);
state.set(e.id, e);
}
});
}
```
You can even go a step further and remove the events all together by returning another higher order function, this way your function doesn't have to deal with `EventEmitter`, but instead with only `Event`.
```ts
const setup = (onEventChange: (e: Event) => void) => {
const state = new Map<string, Event>();
return (e: Event) => {
const proccessedEvent = processEvent(e); // Some function
const existingEvent = state.get(e.id);
if (someComparison(existingEvent, e)) {
onEventChange(e);
state.set(e.id, e);
}
};
}
```
Now this function has been boiled down to it's main purpose, to perform some action when an event has changed based on some state. You can then test this code very easily like this
```
const emittedEvents = [];
const eventHandler = setup((event) => emittedEvents.push(event));
eventHandler({ ...event1 });
eventHandler({ ...event2 });
expect(emittedEvents).toMatchObject([...whatever you want])
```
This way, our tests can focus on the fundamentals, and for the future they can easily show another programmer what the test is focusing on, rather than have them looking at a tone of boiler place. This test will also run a lot faster than if you have to do a tone of setup, although I don't think this is a huge priority.
## Conclusion
It may be difficult to not reach for the solution straight away, as I mentioned the first function I showed is fairly simple and easy to understand, but it isn't testable, and it is heavily coupled.
When you're programming a solution, think about what you're trying to achieve with a specific function, or a specific module, and try and work out the best interfaces and parameters to give this function. A good rule of thumb that I've started using is figuring out how I'd like to test the code, and what I'd like the tests to show, this can lead you to a solution fairly quickly.
This isn't new of course, all I've talked about has been established in software engineering for decades (I've sort of described dependency injection, and interfaces), but it is interest when we see these best practices in our code, and it's exciting to see why they work, it makes programming much more fun for me, because I don't have to keep a massive amount of information in my head (the editor and the computer), but can instead focus on what is right in front of me.

View File

@ -0,0 +1,78 @@
+++
title = "The year of the Camel - Advent of Code 2024"
tags = ["software", "Advent of Code"]
date = "2024-11-28"
author = "John Costa"
toc = true
+++
## TLDR;
I will be doing the advent of code in Ocaml this year.
I've been doing the advent of code since I found out about it in 2019. It's been an exercise that has me reflecting on my growth and development as an engineer, and taken me through many stages in life.
# 2019. The first year.
In 2019, when I first started the challenge, I only completed 4 days. At the time I was in my second year of [Sixth form](https://en.wikipedia.org/wiki/Sixth_form), and had gathered some proficiency in Java, which was the language of choice for my school. However, I did these 4 days in JavaScript and Node.js, as during extra curricular programming clubs, we had been taught JavaScript for game development, where we used it to develop simple 2D games on an HTML canvas, and the more interesting part to me, creating servers using JavaScript, with the infamous Node.js.
Little did I know at the time how much JavaScript and Node.js would shape my career, and although I have strong opinions about both of these tools, I cannot deny that they drove my passion for building things.
# 2020. The tryhard year.
In 2020, I was at home, like most university students were. At this point I was a first year at Royal Holloway studying Computer Science, where the language of choice for learning was also Java.
I didn't find the first year very challenging and being at home I felt even worst, so I look back to December of this year quite fondly, as during a time where I was mostly alone, and with little to do other than work (I had begun my private tutoring career), I spend most of my time doing the advent of code. I managed to stay in the race until day 20.
This marked the start of something great. A love for programming I had previously kindled had now ignited. And from here on out I would spend most of my time behind a screen, typing away, at algorithm problems, and endless side projects.
I have gone back to this year and nearly finished it (I currently sit at 47 stars). This was a very special one for me.
# 2021. The VIM year.
During my second year, I had less time to go deeper into the advent of code. However I still managed to go on until around day 12.
The goal for this year was twofold. I had been loving Golang, having learnt it for a few side projects, and I would still pick this language most of the time. But the main goal wasn't to complete a few days with Golang, it was to only code in VIM - and not some emulator - no, I had to use the terminal VIM, with very little thrills (although I did setup the LSP).
I again look back on this time, because I knew little more than to go into insert mode and just use a keyboard normally. I started to pick up the more complicated keystrokes and some cool motions.
I know use Neovim to develop, and for me, it is the best development setup. I am the most productive, and the most comfortable, when inside a terminal.
# 2022. The TypeScript year.
I had just started my internship at [Decipad](https://decipad.com), where we use TypeScript for every part of the tech stack. And I had enjoyed it.
I was quite a hold out on the TypeScript movement, I didn't see why we needed it. I was more than happy to just use JavaScript and did so for a very long time (even during this period, I used JavaScript for my second year project's frontend).
It wasn't a dislike for static typing, it was simply a matter of not enjoying bloat. To me, it felt weird that we would develop in a language, compile down to JavaScript, and then run said JavaScript. This I know see as a necessary evil, as JavaScript is so very difficult without types (at least on larger codebases).
So I decided to use TypeScript, it was the tool I used for work, so I extended that to my leisure. And it went great. I managed to until day 16, where I stopped as work was ramping up, and I had been put into difficult positions at work, to solve difficult challenges.
# 2023. The Zig and YouTube year.
This year I took it to another level. I had learnt some Zig and completed a simple implementation of [Huffman Encoding](https://johncosta.tech/projects/huffmanz/), but I wanted to learn more about this language. I also wanted to continue working on my [YouTube Channel](https://www.youtube.com/@johncosta27/featured), something I enjoyed whilst working as a tutor.
So, everyday I would sit behind the monitor and record myself walking through the problem in a language that is quite difficult. This took a lot of time and dedication. And I would slow down around day 12, but would periodically post a video. I believe I managed 34 stars during December, and throughout this year, I have gone back and finished off the ones I didn't manage to do at a time. With most of them being on YouTube as well.
After a year of on and off work on it, I finally finished an entire calendar of the advent of code. All 50 stars.
This grew my following a fair chunk to 160 subscribers, and I managed over 1k views on the day 1 video, which is pretty fun.
# 2024. The year of the Camel.
Throughout my time as an engineer, I have always written in imperative-like languages (Java, JavaScript/Typescript, Golang, Zig), and I lack functional experience.
During my last year of university, I had learnt Haskell. It wasn't an extensive course but it was enough to be familiar with the concepts of a functional language. I got enough of a taste to understand why functional languages are an important skill, even if you don't use them in your day to day life.
I have also enjoyed listening to Jane Street's Podcast - [Signals and Threads](https://signalsandthreads.com), where a variety of extremely impressive and interesting engineers talk about Ocaml, from using it in their day to day work, but also from their Compiler's team. These episodes still feel like action movies to me.
My best grade at university was in my Compilers module, taught by [Elizabeth Scott](https://pure.royalholloway.ac.uk/en/persons/elizabeth-scott), who's teaching style and expertise has made me so fascinated by compilers. I achieved an 88% in her class, with my best exam result at university of around 93%.
For this reason I want to explore different languages, understand their syntax choices and the different perspectives an engineer must deal with when faced with functional ML-style languages.
Another professor of mine, Dave Cohen, often said "If you learn another language, you will become better in both". He was refering to learning SVN alongside Git, but the quote still applied everywhere else, and I completely agree with him.
For these reasons, I will do the advent of code in Ocaml this year.
Ocaml is a functional language, similar to Haskell, but a little less hardcore (and actually used in the real world ;) ). It has an impressive community, incredible tooling and a syntax that is not so restrictive if you want to write simpler code. Making it a great stepping stone.
I will also be recording my attempts to YouTube, where you will be able to watch me stumble over myself many times. I hope to see you there.

78
content/blog/sedated.md Normal file
View File

@ -0,0 +1,78 @@
+++
title = "Sedated - By James Davies"
date = "2024-06-02"
tags = ["books"]
toc = true
+++
Sedated is a book about mental health, and the increase is mental illness in recent years - and with that the increase in anti depressants and other psychoactive drugs.
The books revolves around a question. 'If we have increased anti-depressant usage, why are we seeing an increase in mental illness?'. Davies has two ways of answering the question.
1. Anti-depressants are not effective at treating depression.
2. Our economic system increases the amount of people with mental illnesses.
# Are anti-depressants a lie?
Davies presents some very convincing sources, coming up with the conclusion that long term use of anti depressants is almost always detrimental to the user, and even short term use is more often harmful than helpful. The withdrawal from these drugs is also a lot more brutal than the pharmaceutical companies states.
> So why do we use them so much?
## The expansion of mental illnesses.
There is a book called **The Diagnostic and Statistical Manual of Mental Disorders**, it contains all the known mental disorders. Interestingly, the researchers who approve new entries onto this book are often funded by pharmaceutical companies - not only that but the bar required to constitute a mental disorder is really low.
Almost every aspect of human personality can come down to a distorter, every single aspect of a persons emotions can be described by this book in some form of _disease_. From this we can conclude a few things.
- We have expanded the definition of mental disorder, to a point where it no longer means all that much.
- People with perfectly normal personality traits will now be described as mentally ill.
And who wins with all the over-diagnosing?
## Big Pharma and privatised suffering.
We live in a Neo-liberal society, the Chicago School of thought. We allow markets to do what they want with minimal government restriction. Because of this freedom, companies were able to privatise suffering.
We can now buy anti-depressants, to cure the suffering and therefore making money if people are worst off mentally.
Not at all surprisingly, most research that promotes the use of anti-depressants, come out of the research sponsored or conducted by the very companies that manufacture the drugs. The research is often very shaky as well, if not just outright wrong.
This is not to say that the use of anti-depressant is never justified, it is simply stating that many powerful companies benefit if we constantly consume the drugs, for a long time, therefore lowering the barrier to entry is an important goal for them (even if they'll never say it is).
## It is your fault.
This book doesn't just talk about mental illness, it talks about the economic situations which give a rise to not just mental illnesses, but the expansion of this umbrella.
If a person is stressed at work, or suffering from workplace dissatisfaction, it must because because they are not good at managing their time, socialising with co-workers, or doesn't champion the mission of the company. It seems that, today, it is simply not good enough to say that you are dissatisfied with your work, there must be something wrong with you.
- You must be suffering from depression or anxiety.
- Your attitude is incorrect and must be medicated and changed.
- It is simply, your fault.
We don't dare question the atmosphere around us, we don't ask. Is it that the workplace is toxic? Is it that the work feels meaningless? Is the commute not too long? These questions go unanswered, and to _cure_ you, you are medicated, to restore some mythical balance.
Anti-Depressants have become a quick fix to get workers back to work, to allow people to bare the work they do, and it can never be the jobs fault, it must be the individual's fault.
This is one of the reasons for the rise of a type of therapy called CBT (Cognitive Behavioural Therapy). Although I appreciate this type of therapy, and it is useful in helping reshape negative thought patterns, it however shifts the blame to the individual. It's your thoughts that are wrong, it's you who is at fault and who must change and be medicated.
The author made this point extremely well, I started noticing this pattern in many places, from government mental health policy, to NHS therapy. It is really quite concerning that individuals are no longer considered in the mental health debate, but only their usefulness as an economic contributor.
# Conclusion
I am quite concerned about the statistics. The number of adults in the UK who have taken anti-depressants in the last year is 25%. And this is not likely to slow down any time soon.
How long can we go before we have people permanently our of work because they've had enough? And their body simply cannot take anymore?
The rise in the number of people who do not work due to physical and mental disabilities has risen a lot in the last few decades, and I not in any way think that people have become softer, I think these are genuine cases of people becoming disabled because of a very harsh situation that we all go through.
I don't think that Anti-Depressants are bad, or that we are prescribing them to give money to Big Pharma, no. It is a quick fix, a get healthy quick scheme, but one that is extremely short sighted, the long term risks of constant consumption of these drugs will be much worst than the short term positive that people can get back to work.
The book has made me question how we think about mental health, and generally I think we are moving in a _better_ direction, and being more open about it, specially in the workplace. But we must do more. We must stop prescribing anti-depressants as if they are candy, and use them only _after_ therapy has been tried. Therapy has been shown to be extremely effective when done for a few months. But therapy is more expensive than a few pills. I truly don't know what the answer is.
Gloomy conclusion, but a needed one. The world can be harsh, but we are richer than we have ever been, now more than ever we can tackle these problems now that almost everyone's basic needs have been met. We can move on to solving these _first_ world problems.
Thank you for coming to my TedTalk.
## Rating
I would give this a good 7.5/10.

View File

@ -0,0 +1,11 @@
+++
title = "Advent of Code"
date = "2024-11-28"
author = "John Costa"
toc = true
tags = ["Software", "Advent of Code"]
+++
Git Repo: https://github.com/JohnCosta27/AdventOfCode
I'm a massive fan of the Advent of Code, I have created a big mono repo of all the years solutions.

View File

@ -0,0 +1,16 @@
+++
title = "Real Time Trading system"
date = "2024-11-17"
author = "John Costa"
toc = true
tags = ["Software"]
+++
- Git Repo: https://github.com/JohnCosta27/RealTimeTradingSystem
- YouTube video: [https://youtu.be/OlzLp7X_UnY](https://youtu.be/OlzLp7X_UnY)
During my final year at university, I developed a real time trading system as a way to explore distributed systems development.
I built a modular architecture that enabled horizontal scaling, and implemented various strategies for speeding up the application.
You can also check out my final report [here](https://github.com/JohnCosta27/RealTimeTradingSystem/blob/main/final_report.pdf).

View File

Before

Width:  |  Height:  |  Size: 2.6 MiB

After

Width:  |  Height:  |  Size: 2.6 MiB

View File

Before

Width:  |  Height:  |  Size: 2.6 MiB

After

Width:  |  Height:  |  Size: 2.6 MiB

View File

Before

Width:  |  Height:  |  Size: 2.5 MiB

After

Width:  |  Height:  |  Size: 2.5 MiB

View File

Before

Width:  |  Height:  |  Size: 2.6 MiB

After

Width:  |  Height:  |  Size: 2.6 MiB

View File

Before

Width:  |  Height:  |  Size: 2.6 MiB

After

Width:  |  Height:  |  Size: 2.6 MiB

View File

Before

Width:  |  Height:  |  Size: 2.6 MiB

After

Width:  |  Height:  |  Size: 2.6 MiB

BIN
static/map.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 879 KiB

BIN
static/obsidian_menu.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

BIN
static/tasks.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 85 KiB