As you can see, we have linked the same file with two different file pointers. Turns out that with file pointers, we can do
stuff with the files, but only one operation per pointer. In this case, we can do **read** (`r`) and **write** (`w`) the file.
Now, we can do stuff with the files but it depends on the operation. Say that we want to add something to the file, we must add a
file pointer with the write operation saying that "in this file, we can only write stuff in it".
Same with how we would dynamically allocate memory (and if you got some clues from the syntax), we would also close the file
pointer, signifying that we are done with this file. Once we close that file pointer, we can't do stuff with it, anymore. We
cannot read a string from a file, we cannot write some text on a file. We would have to reopen a file pointer for another
operation.
### Planning and Organizing in Programming
> no plan survives contact with the enemy
Quote from Helmuth von Moltke the Elder, a military chief of staff. Well, having a plan is pretty much a good rule in all
disciplines. As said by another military figure, General Dwight D. Eisenhower, that plans are useless but the skill of
**planning** is indispensable. So yeah, that's the point I'm trying to make. Anyways, while progressing through the problem sets
from the CS50 course, I've been forced to be more cautious on coding. Of course, as you might have seen on some of the websites,
programming does not involve coding 100% of the time but debugging and trying to solve a problem, in effect, creating an outline.
I've been pretty much intimated with the problem sets (at the time of this writing, I'm currently on `resize.c`) so I tried and
will try solving the upcoming problems with a different approach. I'll try to keep solving in spirit and continue to improve
my problem solving skills, and in hindsight, planning skills.
Having said that, a plan without organization will mostly ensues a mess. So, make sure that the plan goes with some kind of order.
One of the ways on how to create an organized plan is with an outline which is just mentioned a paragraph ago.
There are plenty of ways to initiate a plan for a different purposes. In my case, I mostly plan with writing everything every idea
I have down on paper and writing pseudocodes from those set of ideas,
statements that represent the action or the function of the code. I generally write the general course of action then inspecting
every list item I've just written then create subtasks, if the task can be broken down further into easy-to-digest statements.
As a self-reminder, I must say that everything should be taken in moderation. The same with staying in the planning phase. You
might create the perfect plan that goes with a guarantee that it will work but just like how most of our process in programming,
we will encounter some obstacle that will eventually render the plan to be a failure. So yeah, don't get too ahead to be like
a strategist to create *the* plan, just make a plan and go ahead with it. If it fails, then create another quick one.
Another self-reminder, don't plan for the big picture. As most programming advice post has said, programming is ultimately about
problem solving and to solve problems, you must take the problem into small separate subproblems that takes small separate
subtasks, and if a subtask can be broken down into subtasks, break it down further. I'm pretty sure you heard and seen that kind
of advice a lot of time so I'll say it again: programming is about breaking things down into small steps that it cannot be broken
down further.
### Processing and p5.js
More Processing because why not? In case you're curious what is it about, Processing is a programming language (or is it a
library because it is said to be built upon Java so...) that lets you create some creative stuff. Anyway, I got the syntax
quickly since most of the programming language use the same concepts, anyway. After getting a bit comfortable with it, I've
decided to go for [p5.js](http://p5js.org/) which is basically Processing except written for JavaScript. I played with a little
bit and created my [first pen](https://codepen.io/foo-dogsquared/pen/LByzzR) that uses the library. This is getting interesting
so far and I might go back study some geometry because of this. Plus, I've been wanting to see some kind of practical (I'm not
sure if this is one) application of the subject, and this is one of the nicest thing I've got so far so I'm going to continue
ahead. And another plus, more stuff to put for the next week entry and it is not all about computer stuff. 😁
## Article of the Week
#### [The Work Required to Understand the Obvious (Or How to Be Wise) by *Zat Rana*](https://medium.com/@ztrana/the-work-required-to-understand-the-obvious-or-how-to-be-wise-e57a6bc542cf)
I took notice of this through inspecting my email and I think this article leaves me profoundly thinking. An article that speaks
the issue which is the things we mostly ignore (that may or may not have values to it) especially the things that have been
discovered long before us (or our acknowledgement of it) and how and why cliches are often undermined. I'm pretty sure there
are some things you all have heard a lot of times to the point of ignoring it either because you've heard enough or you think you
understood it well. Well, this is a chance for you to go for a introspection and perhaps a look into this article as well.
## Books of the Week
#### [Programming Notes for Professional books](https://goalkicker.com/)
I know this has been featured as one of the very much recommended items on my