Week 10 Project, Part 2a: Back on Track

Last week, I wrote about two problems I had moving my project from PhpStorm to IntelliJ IDEA Ultimate (both from JetBrains.com). To recap (or you can read the entire post here), I could not get the deployment configuration to work (I set it up to sync the local sources with the web server on any explicit “Save All”), and I could not get the built-in web server (in the IDE) to open the site for testing – it was always opening the actual site on the web server (which works, but adds some network traffic and some latency).

The solution to the first problem, described in last week’s post, was for me to use the correct path for the local directory where the sources are located. Duh. As I stated last week, this was not in any way the fault of JetBrains or the IDE; it was all my doing.

The second problem I finally solved after I wrote last week’s post. Again, the fault lies solely with me. When I created the deployment configuration (and finally got it right), I had inadvertently set it up as the default deployment configuration. As the IntelliJ IDEA docs clearly state, if a deployment configuration is marked as the default, it will be used instead of the built-in web server (or any other deployment configuration, presumably). As soon as I unset the default, it went back to using the internal web server when I clicked the “Run” button to test the site.

Yes, I know this is a short blog post. I spent way too much time on these two issues – I should have just read the docs (or searched Stack Overflow) right away. Oh well, next time…

Week 10 Project, Part 2: Rabbit Trail Detour

This week was supposed to find the code complete and the web app up (at dev.kobayashicoding.net) and running. As these things go, however, I found myself doing some DevOps instead of coding.

I use JetBrains tools for development. I’ve been using PhpStorm for quite some time, and recently also licensed IntelliJ IDEA because I want to start learning Kotlin (and maybe even bone up on Java). The interface for these IDEs is pretty much identical (as far as I can tell), so I’ve been using IntelliJ IDEA recently, even on projects that I started in PhpStorm – including this current project.

Somehow in moving from PhpStorm to IntelliJ IDEA, I managed to delete the deployment configuration for this project. JetBrains tools – like most others I’ve used – have built-in FTP and SFTP clients to synchronize the local code with the actual web server, and I set mine up to upload any changed files whenever I do an explicit “Save” of all changed files. When I began working on the code again last week, I noticed that neither was the code being uploaded to the server, nor did I have the usual “Browse Remote Host” pane on the right side of the IDE’s window.

A quick look at the deployment configurations revealed that there were none. So, I spent more time that I should have configuring the settings for the host. This was not JetBrains’ fault – I simply failed to use the correct path to the local folder with the code for the site. Once I realized – and corrected – that, the code got synced and the changes I’d just made magically appeared.

I haven’t been as lucky with the other issue that also appeared. Using PhpStorm, I used to be able to run the local version of the site (I’m not actually using any Php, or anything else that requires a real web server), but the “Run” icon in the toolbar was grayed out. So I clicked the “Configurations” button and looked for the appropriate template to use, but have not yet been able to recreate the configuration I need. I guess I’ll have to actually resort to looking at the docs, or even <gasp> contact JetBrains tech support – which is awesome.

Tune in next week for the exciting continuing saga…

Week 10 Project, Part 1: More JavaScript…

No New News Here – I’m Behind!

I’m way behind on my “52 Weekly Websites.” Sigh. I hope to do better going into the new year (2019). I started this venture in October… of 2016! I’ve actually been working on this project – on and off – for a couple of months now. A non-trivial project mixed with a lot of learning apparently takes time.

An Actual Project This “Week”

So, last “week,” I was tinkering with creating content (and menus) using only JavaScript. I learned a lot and I’m happy with the results, so I thought I’d continue with JavaScript for the next project, which is an actual app that I want to be able to use to track business miles in my vehicle(s).

This week’s project will also use the localStorage (or Web Storage) or maybe the IndexedDB features of HTML5 (or maybe both – but I’ll probably start with localStorage). For this project, I want to be able to input data about trips, both local and long distance – date, time, mileage, vehicle, and a short description. I don’t want to have to use a back-end database on a website somewhere for the data storage, so I plan to store it locally in the browser, and then export it to a file that I can use to track business miles.

A Couple of Realizations (Finally)

Woo-hoo! The DOM is a collection of objects! Well, yeah, everyone except for me realized that already. After all, DOM stands for Document Object Model. I guess I just never quite put together that the elements in the DOM for an HTML page were also child elements, which in turn could have child elements. This became important when both sorting the divs for the trip records (but it didn’t dawn on me then) and when creating, harvesting, and destroying the divs for the data entry/edit form (finally, the reality began to seep into my consciousness).

Also, the CSS3 “important!” tag is sometimes, well, important. I spent more time that I should have trying to figure out why some of my styling wasn’t being applied to a specific element. I pored over the styles for the element using the browser’s developer tools, and making changes on the fly to get the result I wanted, but nothing worked. I finally broke down and just used the important! tag and, voila – success.

Details Begin Next Week

Well, that’s the plan. I sure hope I make it. This project will be split up over at least 3 weeks of posts, but not more than 5. Stand by…