Today I shared DeepTownCalc with Reddit, and I got some great feedback. Some spurred additional research, and some gave some great ideas for future development. Here are some things I’ve been thinking about.

1. Viewport metadata - I honestly don’t know why this isn’t built into every browser as the default, but apparently I should be adding this to pretty much everything I do from now on:

   1	<meta name="viewport" content="width=device-width, initial-scale=1.0">

   Because in what world are forms that look like this acceptable? It’s funny how for site that claims, “Websites aren’t broken by default, they are functional, high-performing, and accessible,”[sic] the one thing they’ve done that affects the way the page looks is to add that one piece of metadata.

   If it’s not going to be default browser behavior, shouldn’t every HTML tutorial in the world mention it?

2. Sliders - A user requested the ability to use both coal and charcoal in DTC. I explained the challenge and why I chose to keep them separate, and the user came back with the suggestion of using a slider to indicate the ratio you want to use. The slider itself would come in the styling portion of development (i.e., last), but getting proportional quantities should be doable. That may also be useful for when (if) I make mining times, allowing users to enter a ratio of online to offline time.

3. We don’t need no stinking batches - Apparently something I’ve done has messed up my batch solutions. Gotta figure that one out.

4. Buttons are just buttons - I had originally used preventDefault() on my buttons to keep them from reloading the page. I wondered if that was necessary, and I found that it wasn’t. You just had to set it to <button type="button"></button>. If you tell it that a button is just a button, it’s no longer a submit. But that also means that if you’re in a text field and hit enter, it does nothing. I find that annoying. So I think I’m going to have to go back to preventDefault(), at least for the one button.

5. Stop getting stuff you don’t need - This is something I did when I was figuring out a reasonable algorithm in a spreadsheet. Once you reach a weightedNeed of 0 for a material, it shouldn’t be considering that material anymore when it comes to choosing a mine. If you don’t need any more copper, but you need tons of coal, area 1 { coal: 100 } is better than area 2 { coal: 70, copper: 30 }, but the way it is now, those are both equal.

   I think I can do that at the time when it finds a weightedNeed that’s less than 0. I’ll have to loop through sortingMines and remove it, then recalculate howMuch for each mine. But I think it will make the decisions better. I’ll call it a low priority.

6. Incorporate existing materials - I have to figure out a way for users to include their existing materials. That will affect the chosen mines a lot. It will have to go into makeInputNeeds, before findMines. I can just have it make an array of the materials and quantities, then subtract it from needsList before it starts picking mines.

   The input will take some thought, but maybe I can have it create hidden inputs during displayResults. Then in the click listener, I can have it reuse the loop that makes itemArray. DRY code!

7. Styling - Yeah, it’s last, but it’s going to be annoying. I guess I just want to figure out the full functionality here before I invest a lot of time to how it looks. I don’t want to duplicate much more work than necessary.

   But I do know that I want to use it as an opportunity to learn and practice CSS Grid. I don’t want to rely on any third-party framework. I like knowing that I can use them, but I don’t want to have a crutch. We’re trying to do at least some of these things the hard way, people. I mean, how much easier would a lot of this be in jQuery? Probably a lot.

I fixed the issue from last night where some materials never reached a high enough priority to be mined. As I had planned, I broke miningAlgorithm into two pieces: one that calculates priority and chooses what material to mine, and another, chooseMine, which chooses the best mine where you can find that material.

Unfortunately, that caused another problem, but I’ll have to get back to that. The good thing is that I learned more about using function expressions.

I made a function expression let priority = function () {/* yadda yadda */}. That checked to see if we’re running out of available mines (if (i >= availableMines - minableNeeds)) and we loop through each of the minable needs to make sure there’s at least one mine for each need. If not, the we return the need we’re looking at. If there’s at least one mine, we return the top priority as per miningAlgorithm. If we’re not in the last few available mines, we also return the top priority per the algorithm.

Once I have returned priority I can call chooseMine(priority(), i). I was not expecting to have to use the parentheses in the parameters, but now that I’m thinking of it, that makes sense. It means when it finds that it needs priority, it has to call it as a function. Otherwise, it passes in the text of the function, which helps no one.

And that works great. Except when there are no mines left that contain the designated priority.

Previously, I had been looping through needsList, which was recently sorted by priority. If I ran out of mines for one material, it would automatically move on to the next highest priority.

But now that I’m determining the top priority, I though there would be no need to loop through needsList yet again. I got rid of the loop, and I was happy for slightly cleaner code. Alas.

Instead, of returning priority, I’m going to have to move the position of the desired material in needsList. Then I can loop through it, just as I had been before.

To do this, I think I can unshift() to make room at index 0, copy the desired material, and splice() the old one out. Luckily, I want the priority at the beginning of the array, so I don’t have to go and do something like this.

That also means I probably won’t need a function expression. Oh well.

In DTC, I’m having a problem with prioritizing mines. There are some instances in which a material has such a low priority that none of the ordered mines have the material. I need to make it so at least one mine produces every material.

Right now I’m looking at putting that in miningAlgorithm after the priority has been calculated, but before the mine has been chosen.

First, I need to see how many minable materials I’m working with. I could loop through needsList again, but there may be a better place to do this, such as counting at the time each material is being pushed to needsList. We’ll call that number minableNeeds.

Then, I’ll check to see if we’ve assigned almost all the other mines already. I want the top priorities assigned first, then at the end check for orphaned materials. Something like if (i > availableMines - minableNeeds)

Next I have to go through each of needsList (yet again) to make sure that the material is minable. If it is, check it against sortingMines to see if the material is being mined. If not, then I have to loop through all the mines and find the one with the material and the highest howMuch.

I wonder if looping through the same data over and over is common, or if I’ve set myself up for frustration from the beginning. I also think it may be time to break up some of my bigger functions. miningAlgorithm alone is up to about 85 lines.

Actually, that may be the solution to my problem. If I split the second half of miningAlgorithm into its own function, I can pass it any material I want, not strictly the material with the highest priority.

So I’ll calculate the highest priority in one function, then decide whether I need to override that priority with an orphaned material. The winner of that battle gets passed into the mine choosing function.

I’ll get to work on that tomorrow.

I made a friend last night.

I was in the middle of setting up this very Hexo blog when he flew in and circled the living room a few dozen times, looking for a way out.

Eventually, he landed in a basket, so I threw an old towel over it and took it outside.

Reddit says it’s probably a big brown bat.

Farewell my friend! Gorge yourself on all the insects you like, just stay out of the house next time.

I used to think that I didn’t know much. Learning coding has opened my eyes as to how much more I didn’t know that I didn’t know.

I am learning a great deal, but it’s becoming increasingly difficult to remember the details of what I’ve learned. This blog is intended to counteract that. First by writing down and trying to explain to myself, rather than simply using what I’m learning, the lessons should be reinforced. And second, this will be a searchable record of my own challenges and questions, as well as the resources I’ve used to progress.

It’s been 8 or 9 months since I’ve been learning in earnest, and I think I’m approaching passably adequate at introductory HTML, CSS, and JavaScript. It’s hard to tell, as I have no immediate colleagues to whom to compare myself. That’s probably something I should change.

I’m starting to hear the Doogie Howser theme in my head, so I’m going to bed and hope I don’t dream of code. Again.