van2z

Let me start by noticing, I am not interested in playing a game of Tic Tac Toe, nor programming any form of "AI". With that out of the way, let me give some background:

I have found Rust, with its ownership model, frequently nudges me to rethink whatever I am building. Usually it involves fixing some structs / enums, to avoid references. Correctly structuring an object can make me avoid lots of headaches later when I actually add functionality.

One thing I noticed that helps is understanding what kind of properties should the data have? Should it maintain a certain order, or can it be unordered? Are all of the values unique, or can it have duplicates? All of these details are very important. It is wrong to just shove everything into a Vec. A Vec implies ordering and duplicates, which could be a bad model. We need to choose something which most closely represents the data.

Ok, enough lecture. Onto the Tic Tac Toe grid. Observing this grid provides me with a few important properties:

A Tic Tac Toe grid can be rotated clockwise or counterclockwise, and the game is still the same. The grid can also be flipped over horizontally or vertically and the game will be the same. To decide if anyone won, we just need to see if any rows have 3 of the same value. The rest of the grid does not matter.

I am trying to figure out the best memory model would best represent this behavior. How to build a grid whose orientation does not matter?

Ideally, all of these values should be represented in memory exactly the same way:

  X|O|   X| |    | |
   |O| = O|O| = O|O|
   | |    | |   X| |

But how to do this? One way I was thinking, is perhaps instead of saving a grid at all, we should just be keeping track of all of the rows.

• [X, O, E] (E = Empty)
• [O, O, E]
• etc for all the other rows..

However there are several problems with this model:

1. The same cells are owned by multiple rows. This is not good. Perhaps the rows can hold a reference to the cells?
2. The ordering of each row should not matter. So this shouldn't be an array. A better representation may be a Set or Bag/Multiset.

#1 continues to bug me. If we have rows holding references to all of the cells, then it will be hard to update any of them because of rust's restrictions on multiple mutable borrows. Or am I wrong here? How can I update a cell using a reference from a row? Where would the cell live anyway?

It doesn't seem to help to declare the rows inside of the cells, because that leads to cyclical references.

I continue to mull over this problem with not much success. I hope someone can help me discover a better path forward.

For some reason, it seems popular for GUI crates to use the GPU. I just want to make simple widgets, for like a calculator.

No fancy graphics. I want it quite lightweight.

For some reason, popular GUI crates love to do everything through a GPU, which bumps up the memory / cpu use significantly.

I just attempted to write up a simple Minesweeper game with Iced. No bells or whistles, but it works:

https://github.com/veniamin-ilmer/minesweeper

On one hand, I find it pretty cool I built a clear cross platform GUI with actual functionality, within only 200 lines of code.

On the other hand, I can't help but see how inefficient it seems. If I ever need to modify any of the objects, I need to redraw all of them. The structure of the view method makes me think it is very difficult for Iced to maintain a "virtual DOM" to only make delta changes.

Am I wrong? Is there a more efficient way to do this in Iced?

Edit: I just found this - https://github.com/iced-rs/iced/pull/1284

As the library matures, the need for some kind of persistent widget data (see #553) between view calls becomes more apparent (e.g. incremental rendering, animations, accessibility, etc.).

If we are going to end up having persistent widget data anyways... There is no reason to have impure, stateful widgets anymore!

So it seems like Iced plans to have an internal "persistent widget storage", which in abstracted away from the user. But it is quite unclear to me how they would accomplish this, considering the view method doesn't provide an ID for any of its objects, so it would not be easy for Iced to determine the difference between updates.

cross-posted from: https://programming.dev/post/864349

I have spent some time trying to simplify the release process. For a variety of reasons, we can only release on Thursdays. The code is "frozen" on Tuesday before it can be released on Thursday. But we sometimes squeeze in a quick fix on Wednesday as well.

The question, is when should QA test the code?

Here is what I have seen happen:

1. Dev writes code and sends it to QA.
2. QA finds problems, sends it back to the Dev.
3. Dev fixes and sends it back to QA.

I have seen a Dev fix their code on Tuesday, and then QA comes back on Wednesday with problems, when the code should have been frozen anyway.

I am looking, what should be the best solution here.

We have several problems going on at once:

1. Developers test on the same server as QA tests. I am working to switch developers to a separate Dev server, but it is a long work in progress.
2. We don't have an easy way to revert code back from the QA server. It is easier to build revisions than revert changes. We can try to revert code more, but it will require a culture change.
3. QA don't really have a schedule when they are supposed to do functional testing vs regression testing.

I don't know what is the best way to proceed forward. Thus far, I haven't thought too much about the QA because I was focused more on getting releases out. Now that releasing is more simplified, that we can potentially do weekly releases, I am trying to see how we should proceed with the testing process.

I have spent some time trying to simplify the release process. For a variety of reasons, we can only release on Thursdays. The code is "frozen" on Tuesday before it can be released on Thursday. But we sometimes squeeze in a quick fix on Wednesday as well.

The question, is when should QA test the code?

Here is what I have seen happen:

1. Dev writes code and sends it to QA.
2. QA finds problems, sends it back to the Dev.
3. Dev fixes and sends it back to QA.

I have seen a Dev fix their code on Tuesday, and then QA comes back on Wednesday with problems, when the code should have been frozen anyway.

I am looking, what should be the best solution here.

We have several problems going on at once:

1. Developers test on the same server as QA tests. I am working to switch developers to a separate Dev server, but it is a long work in progress.
2. We don't have an easy way to revert code back from the QA server. It is easier to build revisions than revert changes. We can try to revert code more, but it will require a culture change.
3. QA don't really have a schedule when they are supposed to do functional testing vs regression testing.

I don't know what is the best way to proceed forward. Thus far, I haven't thought too much about the QA because I was focused more on getting releases out. Now that releasing is more simplified, that we can potentially do weekly releases, I am trying to see how we should proceed with the testing process.

I recently decided to think of an algorithm based on natural selection of DNA mutations. Being unclear about its speed complexity, I decided to write it up and test it out. The result was counter intuitive.

First, a simpler variant: Imagine the following sorting algorithm, given an array of numbers: Randomly shuffle the numbers until they are sorted.

What is the median amount of times you end up shuffling the array before it is sorted?

The answer is n! where n is length of the array. This is known as Bogosort.

Now, a slightly more advanced version:

Assume you can tell which numbers are already in their correctly sorted position, and which aren't. Only randomly shuffle the numbers which are not yet sorted. Keep all the others in place.

What is the median amount of times you end up doing this kind of shuffling before the whole array is sorted?

I'll be revealing the answer tomorrow.

Edit: The answer is that you end up shuffling only n times.

Addressing some concerns: this is not a real sorting algorithm, because it assumes you already know whether some of the records are sorted or not.

It shows me how "random chance" in DNA mutations can actually occur much faster than we expect. When a better gene allows an organism to survive better, it sticks around, while all of the other useless genes randomly shuffle around until they can become more useful too. This way organisms with a long DNA code can still evolve rather quickly even if it's by random chance.

I have about 13 years of tech experience. Some as a software dev with open source languages, some as an on-site consultant with proprietary languages.

My first experience as a lead came involuntarily. I was the most senior dev, and a lead left the company. I was kind of forced into filling his role. I am in the US, and the 3 or so people under me were all from India. The time zone difference made communication with them very hard. I didn't enjoy the position. I felt as if I had more responsibilities without more authority. I left shortly afterwards.

At my next few jobs, being a dev felt like I was on "easy mode". Almost too easy. I started to feel that I have nothing new to learn as a dev... All of the frameworks seemed the same to me, just regurgitating the same functionality in a different format.

Onto the company where I am now: I started as a dev. Although I was getting lots of work done, there was a clear vacuum of leadership. Poor communication, lots of technical debt, new people had no guidance and had to learn everything on their own.

I told management multiple times that we lack a lead, and asked if we would be getting one. After several months, management asked if I would be interested in being the lead. Especially with regards to dealing with the technical debt. I said yes, because I felt I was filling a very important yet lacking void.

That was 6 months ago. Things have been quite exciting since then. For the first time in forever, I actually felt challenged, doing new things. I have been on my toes, switching from one issue to another. It started with handling the technical debt, then training the new people, then trying to use the team resources most effectively. Along the way, I have been gaining the trust of the people I lead, acting as the communication glue of the team, and being transparent with everyone.

I end up having to handle everything that is not a coding task. This included creating new access roles, assigning them to people and to service accounts, configuring message queues, releasing code, etc.

I would love to delegate some of this stuff. The problem is my boss took on too many projects and was forced to take a bunch of people from my team to cover those other projects. I am left with few people, running quite lean.

Much of the people working in the team are quite shy, or not very good at communicating. I end up being the speaker for much of the team, especially when talking up with management.

Last month, a person on my team asked to talk with me privately... She then told me, her contract is being cut short, ending work that week. The sad part is, she found this out from her contracting agency. No one told her about it up till then.. And then she basically started pleading with me if there was any way she could keep her job. This made me quite sad and angry. I called up several managers involved, and had a long discussion with them about us losing a great resource, lack of communication, etc.... And incredibly, they listened to me. Sparing the details, l was able to keep her contract from ending.

Since then, I have felt quite confident in my position, being respected by both my team members and also my bosses. I started having one-on-ones with everyone making sure they are happy with what they are doing..

I have started to question, am I a lead or a manager? Although I do look at code when it needs to be done ASAP, for the most part I prefer to have someone else work on it. I don't really want to be the architect / designer of new code. I hope my team grows strong enough to make these decisions themselves.

Recently I told the team, we need to speed up our GUI and asked if anyone has any suggestions how to do this. My main GUI guy provided an idea which will require a lot of time and effort. But I can see it has potential. I told him to to for it, build a POC. I would like to encourage this kind of attitude more, for people to come up with their own solutions instead of just waiting for me to give them work..

In any case, this has been an exciting journey. It has really worked out well. I am lucky people listen to me. At least for now. I do continue to wonder, am I a lead or a manager?

Not only will a bidet save you on toilet paper, but you will actually feel like you have a clean butt after pooping. Initially it feels weird, but after you get used to it, you won't want to poop without it.

BTW in case you are wondering: yes, you still need toilet paper to wipe the water off. But it is a small amount.

I have been working at a large bank for a few years. Although some coding is needed, the bulk majority of time is spent on server config changes, releasing code to production, asking other people for approvals, auth roles, and of course tons of meetings with the end user to find out what they need.

I guess when I was a junior engineer, I would spend more time looking at code, though I used to work for small companies. So it is hard for me to judge if the extra time spent coding, was because of me being a junior or because it was a small company.

The kicker, is when we interview devs, most of the interview is just about coding. Very little of it is about the stuff I listed..