## Thursday, July 20, 2023

### Background music for coding - playlist

It's only an hour or so at the moment but nonetheless - this is a collection of music I listen while coding. I hope to expand the list in future.

### Rust binary tree with iterator

For few days I scratch my head over Rust. Never tried it before, not going to be a Rust developer but I feel I'm missing new challenges and this looks like one.
While the official docs are rather concise, there are good books, the Programming Rust: Fast, Safe Systems Development 2nd Edition by Blandy/Orendorff/Tindall is really good and it feels like it's written by folks who really like to help the reader. A lot of good examples and the background I missed in the official docs.
Anyway, my first successfull attempt at something not-that-obvious, a binary tree with an iterator. Doing this in C# would be a breeze, Rust had some surprises around every corner. I am lucky to have Łukasz who answers my questions, corrects my mistakes and gives critical hints on specific problems. Thanks!
The code below. For anyone wondering how much time did it take, starting from zero knowledge of the language to this point - few hours reading the book and then like 5-6 hours to get this result.
```use std::fmt::Debug;

struct TreeNode<'a, T: 'a> {
val  : &'a T,
left : Option<Box<TreeNode<'a, T>>>,
right: Option<Box<TreeNode<'a, T>>>
}

impl<'a, T> TreeNode<'a, T> {
fn new(
val: &'a T,
left: Option<Box<TreeNode<'a, T>>>,
right: Option<Box<TreeNode<'a, T>>>) -> Self {
Self { val, left, right }
}
}

/* C#'s IEnumerable on TreeNode - returns an iterator/enumerator */
impl<'a, T> IntoIterator for &'a TreeNode<'a, T> {
type Item = &'a TreeNode<'a, T>;
type IntoIter = TreeNodeIterator<'a, T>;

fn into_iter(self) -> Self::IntoIter {
TreeNodeIterator::init(&self)
}
}

/* C#'s IEnumerator */
struct TreeNodeIterator<'a, T: 'a> {
stack: Vec<&'a TreeNode<'a, T>>
}

impl<'a, T> TreeNodeIterator<'a, T> {
fn init(node: &'a TreeNode<'a, T>) -> Self {
Self { stack: vec![node] }
}
}

impl<'a, T> Iterator for TreeNodeIterator<'a, T> {
type Item = &'a TreeNode<'a, T>;

fn next(&mut self) -> Option<Self::Item> {

if self.stack.len() > 0 {

let curr = self.stack.pop()?;

/* one way to tackle the child noe */
if let Some(right) = &curr.right {
self.stack.push( right.as_ref() );
}
/* another way of doing the same */
if curr.left.is_some() {
self.stack.push(curr.left.as_ref().unwrap());
}

return Some(curr);
}

None
}
}

/* auxiliary code to be able to test the enumerator */
struct TreeNodeUtility;
impl TreeNodeUtility  {
fn do_work<'a, T> ( node: &'a TreeNode<'a, T> ) where &'a T: Debug {
for n in node {
println!("{:?}", n.val );
}
}
}

fn main() {

let s1 = String::from("1");
let s2 = String::from("2");
let s3 = String::from("3");

let root = Some( TreeNode::<String>::new(
&s1,

Some(Box::new(TreeNode::<String>::new(
&s2,
None,
None
))),

Some(Box::new(TreeNode::<String>::new(
&s3,
None,
None
)))
) ) ;

if root.is_some() {
let rootc = root.unwrap();
TreeNodeUtility::do_work( &rootc );
TreeNodeUtility::do_work( &rootc );
}
}
```
After consulting the clippy and trying to improve the code further, I came up with following changes:
• changed the type of the iterator's item to &T from &TreeNode<T>
• changed the TreeNodeIterator to a tupled struct (a struct with just a single field that doesn't even need a name)
• dropped the init method of the iterator struct
• changed the "if non empty stack - pop" code into a single liner
• changed the "if option is some - do" code into a single liner
```use std::fmt::Debug;

struct TreeNode<'a, T: 'a> {
val  : &'a T,
left : Option<Box<TreeNode<'a, T>>>,
right: Option<Box<TreeNode<'a, T>>>
}

impl<'a, T> TreeNode<'a, T> {
fn new(
val: &'a T,
left: Option<Box<TreeNode<'a, T>>>,
right: Option<Box<TreeNode<'a, T>>>) -> Self {
Self { val, left, right }
}
}

/* C#'s IEnumerable on TreeNode - returns an iterator/enumerator */
impl<'a, T> IntoIterator for &'a TreeNode<'a, T> {
type Item = &'a T;
type IntoIter = TreeNodeIterator<'a, T>;

fn into_iter(self) -> Self::IntoIter {
TreeNodeIterator(vec![self])
}
}

/* C#'s IEnumerator */
struct TreeNodeIterator<'a, T: 'a>(Vec<&'a TreeNode<'a, T>>);

impl<'a, T> Iterator for TreeNodeIterator<'a, T> {
type Item = &'a T;

fn next(&mut self) -> Option<Self::Item> {

if let Some(curr) = self.0.pop() {

/* one way to tackle the child node */
if let Some(right) = &curr.right {
self.0.push( right.as_ref() );
}
/* another way of doing the same */
if curr.left.is_some() {
self.0.push(curr.left.as_ref()?);
}

return Some(curr.val);
}

None
}
}

/* auxiliary code to be able to test the enumerator */
struct TreeNodeUtility;
impl TreeNodeUtility  {
fn do_work<'a, T> ( node: &'a TreeNode<'a, T> ) where &'a T: Debug {
for n in node {
println!("{:?}", n );
}
}
}

fn main() {

let s1 = String::from("1");
let s2 = String::from("2");
let s3 = String::from("3");

let root = Some( TreeNode::<String>::new(
&s1,

Some(Box::new(TreeNode::<String>::new(
&s2,
None,
None
))),

Some(Box::new(TreeNode::<String>::new(
&s3,
None,
None
)))
) ) ;

if let Some( rootc ) = root  {
TreeNodeUtility::do_work( &rootc );
TreeNodeUtility::do_work( &rootc );
}
}
```

## Wednesday, July 5, 2023

### Notes to myself-from-the-future

The more code I write over the years, the more additional non-code information I tend to leave to myself from the future. The additional information, put in inline comments, comments in signatures, external markdown files, is intended to be targeted exactly to me from the future.

It usually starts when I look for something. Like for example - an ASP.NET application, something that looks like it works upon each request but there's no visible sign of a public http module registered in web.config. Since that's odd, I go to the global.asax and try to find a module registered programmatically (rather than declaratively). And then I remember - "wait a minute, I remember myself searching for the same information some time ago".

This is where I make a conclusion - if I search for something and I remember searching for it at least once before, I try to think like myself-from-the-future. Where would I search for this information next time? Well, I am in global.asax now, so there's a high probability that the future-me will also come to the global.asax.

I decide to use the global.asax then and I leave a note to myself-from-the-future - If you search for [....], this information is in [....]"

Looking for various information, I then am grateful to myself-from-the-past - I often just stumble upon these "If you search for ... this information is in ...." which means that at some point in the past I tried to think like the present-me and my prediction at that time was correct. And often, I have no memory of writing these notes, I just see them in the code, I belive I wrote them at some point, I can even check the source control and find the exact date. But I just don't remember writing it at all.

All these notes I send to myself, from the past to the future, are nice and useful and somehow let me feel like the past-me and the present-me is for sure the very same me, despite the time that passes. Things change but the way I think about myself is solid.

Today was the day I tried to find something in the code. The code is an old desktop utility app that registers some HTTP listeners at start. There are multiple places listeners can be added, in the Main function, in the main form's constructor, in the main form's load event etc. At first I've assumed the myself-from-the-past would possibly leave a note to the present me somewhere.

I've checked few obvious places. Is there a global markdown file for such notes? Nope. Is there a comment in the main *.cs file? Nope. Is there a comment in the form constructor? Nope. Is there a comment above the form class definition? Yes, there is but the summary section doesn't seem to contain any information about registration of HTTP listeners.

So I've spent like 3 minutes to track down the registration. Found a method that does it. Found a reference to the method. Tracked the reference, until I've ended up in form's Load method.

Just leave a note to myself-from-the-future - I thought. Next time I will try to search for it, I will probably go to main form class and a comment above it. The place that already contains the summary section but lacks the information about listener registrations.

So I go there, go to the very bottom of the summary section, since it spans a dozen of lines I carefully navigate to its ending to put a new line with the new information about the registration of HTTP listeners.

And guess what. The summary section ends, the remarks section starts there, a section I obviously missed few minutes eariler (I just haven't noticed it's there, I thought the whole green block of comment lines was the summary section)!

And the only line in the remarks section is: If you search for registration of HTTP listeners, it's in frmMain_Load

I swear it was not there few minutes ago ... But the fact that I've spent few minutes doing something I thought I hadn't done before but ultimately looks like I had, is kind of reassuring.