Skip to content

Commit

Permalink
Multiple things:
Browse files Browse the repository at this point in the history
- added utility script to convert markdown note into blog
- added new blog post
- updated some details: info about ssl and my age
- changed list of projects - I still need to change it, it contains old projects that seem too trivial to be shown - I like them, though
  • Loading branch information
zostaw committed May 11, 2024
1 parent fa3e062 commit 5558167
Show file tree
Hide file tree
Showing 10 changed files with 258 additions and 17 deletions.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ Or build image yourself:
IMAGE_NAME="zostaw/multiarch-home-page"
IMAGE_TAG="latest"
docker build -t $IMAGE_NAME:$IMAGE_TAG .
docker compose -d
docker compose up -d
```

### Kubernetes
Expand Down
3 changes: 2 additions & 1 deletion app/app.py
Original file line number Diff line number Diff line change
Expand Up @@ -100,14 +100,15 @@ def blog():
{'name': "Learning",
'list':
[
{'url': "engineers_memoir2", 'name': "Conceptualizing projects"},
{'url': "engineers_memoir", 'name': "Becoming an engineer"},
{'url': "drawing", 'name': "Learning to draw"},
]
},
{'name': "Making sense",
'list':
[
{'url': "who_are_we", 'name': "Who are we"},
{'url': "who_are_we", 'name': "Who am I"},
{'url': "fear_of_existence", 'name': "Fear of existence"},
{'url': "dionysiac_architects", 'name': "Dionysiac Architects"},
{'url': "mystory", 'name': "Childhood aspirations"},
Expand Down
Binary file added app/static/images/cnn_featuremaps.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added app/static/images/cnn_heatmaps.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
111 changes: 111 additions & 0 deletions app/templates/blog/engineers_memoir2.html
Original file line number Diff line number Diff line change
@@ -0,0 +1,111 @@
{% block content %}

11.5.2024

<p>Sometime ago I shared a post on work confluence.
It contained a description of an idea.
At that time I didn't know confluence sends anything but random recommendations, so I thought the page will not be read until few years later when somebody finds it by accident.
The day after I received few messages - they were filled with kindness and encouragement.
It's pleasant to get encouraging messages, it fills you with sense of comradery, it elevates you - it's also mobilizing. </p>
<p>At the same time I shared the post, it got to my attention that similar project is already in place, so I asked if I can join.
Organized projects are good - they provide justification for work that is otherwise ignored or discouraged by the system - it works with metrics and it's difficult to define it for creative work or exploratory ideas.
I am aware the term <em>system</em> is loaded. For some, it's a miningless word that people use to wave at injustices. For others - including me - it represents a flawed, rigid structure that was created with good intentions to solve a set of visible problems.
I joined the project.
Over the next few months I learned that, although it's good to think about all the details of the project upfront,
ultimately it's much more than just the ideas and the code - especially if you work in <em>collaboration</em>.
It involves all sorts of other important elements that are essential to actually bringing them to realization.
Ultimately, if you work in a pre-set structure and you want to complete an objective, you must understand how the structure works, learn the language - how to communicate, how to articulate thoughts. If you do not acknowledge those, you'll end up with an aspiration and nothing else, because the system will crash you :)
I do not mean to say that system is bad by definition - but it's non-optimal. It contains a lot of processes that were set up to solve certain problems, to ensure bad things do not happen, sometimes to add clarity and standardize stuff, so that it can be reused or built upon. Sometimes there is an aesthetic value to them.
But very often the processes are very mechanistic and abstractions we set in place create obstructions.
It might cause a lot of frustration, but it's important to focus on what we can control.
Sometimes there are shortcuts and sometimes there aren't - in which case and the most optimal way might resemble <a href="https://en.wikipedia.org/wiki/The_Trial">The Trial</a> more than anything else. In such case one must buckle up, silence the ego and act accordingly - the alternative is even less enticing. </p>
<p>Of course, the time is never completely wasted - it provides an opportunity to read, learn, listen - play.
When we're waiting, we're also more likely to notice flaws in our thinking.
Sometimes, you get to think about some of the stuff that you ignored until then. </p>
<p>So, regarding control - it's important to divide the process into pieces in a way that each component can be distinct from one another.
This ensures that when you're blocked - you're not immobilized. You can always push forward... something.
But to do that one must understand the concept/system he is operating within.
I was thinking about it a lot recently and I think there's probably multiple ways in which we conceptualize things,
but one that I find pretty intuitive is to first get the big picture, to have a complete picture of the <em>solution</em> and then move down in the abstraction to get details of each thing. For example when you're building a house you want to first imagine the complete house, you don't start with a single brick.
But you should also not attach to specific ways in which you imagined it at first.
Once you've got that you want to understand what does it take to build a house - what makes a house, what you need to know about the fundaments, the roof, the isolation, electricity and so on.
Then you want to understand the process - the steps - you can't build a house starting with a roof.
And then... you follow the process.
So, you start with the picture, then move down to divide it into smaller and smaller pieces, and you start at the bottom - piece by piece. </p>
<p>Francois Chollet in his book <em>Deep Learning with Python</em> suggests following workflow (this is paraphrased):
<ul>
<li>define the problem at hand</li>
<li>understand the broader context - end goal and constraints</li>
<li>collect and understand data</li>
<li>choose metrics for success</li>
<li>expectations</li>
<li>develop the model </li>
<li>test</li>
<li>deploy</li>
<li>monitor the performance</li>
<li>maintain the model (update - optimize - improve)</p></li>
</ul><br>
<p>This might sound overwhelming, but it's actually really helpful. Basically what it made me realize is that we don't need to keep everything in head all at once: deployment is a completely different problem than developing the model.
Once you see it, it becomes clear that it's not a sequence, it's... puzzles - you notice a meaningful fragment and build around that, someone else notices another fragment and builds around that - simple. Sometimes one section gives you hints about the positions and stuff. At last, you'll need to finalize - fit those few unconnected puzzles to link sections together into one whole. </p>
<p>But even those pieces are too big. You can pick any part and divide it further. As long as you remember about compatibility between the pieces, you're good to go - isolate them. Most of the time you can. For instance in same book, Francois shows ways of deploying the same exact model in different languages - using <em>Keras</em>.
Sometimes, frameworks you choose enable you to do that (Keras is a good example),
sometimes you might decide to change it or even completely abandon during implementation.
There's an infinite number of ways we can express the same concept: different languages, different sentences.
Similarly, the same program can be described using different set of functions or multiple languages.
So, once you understood and written the concept in one language/framework, the only thing you need to do is to translate it.
In many cases the difference is purely syntactical. </p>
<p>Another important thing is that time you spend on practicing, learning, prototyping is never wasted.
I found it very helpful to start with the concept - it can be a bold concept - you will probably fail the first time anyways and if you pick a bold one, you get to see high-level problems that you need to understand.
Try to visualize the simpliest way to achieve it, then start with that.
It's not important to understand everything all at once.
But eventually you want to understand why it works (as soon as possible).
Notice, when you realize you don't know something and write it down.
Usually, you don't need to come back to the list, you just become aware of it.
But the end of the first <em>run</em> you will see what are important pieces of the concept.
Once you have it, you can start breaking things apart.
If you can afford it - try to start from the fundamentals. But not always we can afford to do it.
In that case you need to balance between:
<ul>
<li>play (implementation of the project with limited understanding) </li>
<li>learning fundamentals (practicing understanding in purely abstract environment, or good example that works well with the concept)</li>
</ul><br>
You also want to spend some time with a book, then put it into practice, there's no rule for how long for each. Sometimes it can be weeks of reading, then weeks of working. Other times it's both at the same time.
A good rule is to start practicing as soon as you get the basic concepts - it helps to cristalize the understanding and allows to link the future concepts to something real.
If you delay practice for too long, you'll not remember anything and you'll need to read everything again.
A good method is the Feynman Technique. It's really difficult at first, but once you get a hang of it - becomes you become better at it when applying to new subjects. </p>
<p>As I mentioned it's good to start with the fundamentals - if you don't have time to start at the very bottom - try to be aware of what you know and what you don't.
Sometimes, there are soo many things that you might look at one and start to wonder "is it worth my time?" It's a valid question.
I think one way to answer it is by realizing the three:
<ul>
<li>there is only limited amount of knowledge that we can consume and process, </li>
<li>there's only limited amount of time we can spend on practice and active learning,</li>
<li>action that reinforces current state is (kind of) wasted</li>
</ul><br>
The last one might sound harsh if what we understand by that is that one should constantly push himself out of comfort zone, yada, yada, yada.
But actually it is not intended to criticize non-action or a convoluted one.
The point is that one should act purposefully - if the objective is to achieve X, then one should act accordingly.
There's always an objective, it's impossible for a human being to act without it.
Sometimes it's explicitly defined goal, other times it's a need that comes from our body.
One should try to determine them - the more you understand what they are, the clearer the picture of what is the stack of importances given to each of them.
We don't have a single goal, but we have multiple on different levels. The highest level is sense of purpose, the lowest one is unconscious desire of the body.
The more we observe ourselves the clearer it becomes what those are and how they align or contradict each other.
<em>Mortimer Adler</em> in <em>How to read a book</em> makes a distinction between two types of books: theoretical and practical.
The former deals with <em>what is</em>, the latter with <em>how to</em>.
On a surface level this distinction might appear as definitive, but it's actually meant to distinct between the format of knowledge, he later says:</p>
<blockquote>
<p>Some books and some teachers are interested only in the knowledge itself that they have to communicate.
This does not mean that they deny its utility, or that they insist that knowledge is good only for its own sake.
They simply limit themselves to one kind of communication [...]
These others have an interest beyond knowledge for its own sake.
They are concerned with the problems of human life that knowledge can help to solve.
They communicate knowledge, too, but always with a view to and emphasis upon its application.
To make knowledge practical we must convert it into rules of operation.
We must pass from knowing <em>what is the case</em> to knowing <em>what to do about it if we wish to get somewhere</em>.</p>
</blockquote>
<p>I'm bringing up this quote, to illustrate that we don't live in a world of cut distinctions - every action has billions of consequences and effects that are not apparent.
It's really difficult to point to one action and say "this is objectively better than others" - in fact if you look at the greatest achievements of humanity, they're usually preceeded with scepticism and disinterest from society - the pursuit of those inventors/thinkers is seen as non-optimal, even though it often is the most optimal to delay the effects of action.
One should apply the same rule to his own life - to look wholisticly to all actions.
Those are always individual, but in some sense they are universal. The means are universal, if you think about it. Everything applies to everyone ever at any time, it's just the details - the conditions - that are different.
One thing is true no matter what circumstances we are at: "inteligent action depends on knowledge" (M. Adler).
If we want to make intelligent actions, we should try to seek to balance between problem at hand and pursuit of completion, and understanding the conceptual framework of this problem. If we only focus on the former - the result will be poor, if we only focus on the latter - the result will be NULL. </p>
{% endblock %}
2 changes: 1 addition & 1 deletion app/templates/blog/mystory.html
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
<!-- Page content -->

<p>
I am a 29 year old fellow who wanted to become an astronaut or a physicist. SPOILER... I am neither :)
I am a 30 year old fellow who wanted to become an astronaut or a physicist. SPOILER... I am neither :)
I do not remember my childhood or adolescence well, but I remember I was always fascinated by stories and the greatness of humanity: all the amazing projects and achievements we made and most of all - the creativity of the human mind in searching for truth.
When I was a child I was obsessed with logic and imagination... and human mind. All the things that make us tick. But only from a distance as I was straining from the interactions with other beings. I thought I was always saying wrong things, accidently offending people. Now I don't think that way, I think I'm learning :)
</p>
Expand Down
2 changes: 1 addition & 1 deletion app/templates/index.html
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@

<div class="container">
<!-- Page content -->
<p>Sorry with the inconvenience with SSL key. I'm waiting until June to refresh both SSL cert as well as domain subscription. Otherwise I have to refresh in different times of year and I don't like it :)</p>
<h1 style="font-size: 25px; text-align: center;">Mateusz Kowalkowski</h1>

<p>
I'm a customer supporter in fintech company. Currently working as Senior Engineering Support Advisor at Finastra.
</br>
Expand Down
Loading

0 comments on commit 5558167

Please sign in to comment.