(This post should have been uploaded in November, 2017, when it happened. I should post more often.)
I noticed that the Angular.io docs were written with Angular 5 in mind. I especially noticed it when the Http methods did not load properly in my project. It turns out that HttpClient was moved to into @angular/common. However, my version of Angular had HttpClient still in @angular/http. I ended up with bad files when I followed the documentation. To stay current, I decided to update my copy of Angular 4 to Angular 5.
I did a search on how to do the update and I ran across this site: angular-update-guide.firebaseapp.com. Their suggestions helped a lot. I did notice that when I ran the update, I kept seeing messages about ‘invalid’ modules. I’m still not sure why I saw that message, but I’ve seen odd messages from other updates before, so I filed it away to follow up in case the update did not work.
I run my development server with Angular CLI, so I entered ‘>ng serve’ to start the new server. It did not work. I saw an odd message saying my version of ‘angular/compiler-cli needs to be 2.3.1 or greater. Current version is 5.0.2’. Clearly, something was wrong with the angular-cli files. I considered updating the project.json file and updating everything with npm. It turns out I had to be more systematic to make sure everything related was updated properly.
I installed Angular-cli globally, so I had to remove it globally first. I also removed it from the dependency list in the project. I deleted the node modules to make sure every change shown in project.json was accepted correctly. I reloaded angular-cli globally and in the project dependencies again. Finally, I ran ‘>npm install’ to make sure the modules were fresh.
‘> ng serve’ worked as expected. That took longer than I thought.
I needed to write some data to a MySQL database. I set up the MySQL Python connector without any real trouble. I tested it in a tiny Python page and it does connect to the correct database. Great!
I moved the connection code to a function on a new page and ran into trouble. I kept seeing a message saying something about “Reference error: weakly-referenced object no longer exists”. After a detour into weak references, I realized the issue was garbage collecting. Somewhere within my function, I had a object that was disappearing.
The connection function had no parameters. A connection object local to the function was created and the resulting cursor was returned. You should see the problem immediately. The connection object what the item that was disappearing. I rewrote the function to send back the connection object and then extract the cursor from the returned object. That error message went away.
I had another strange problem where updating a field was not allowed because of a type mismatch. I’m used to PHP, where weak or loose types are the norm. Once I realized that data going into the MySQL table also needs to match the correct type expected by the MySQL column, my problem is solved.
I have some more free time, so I decided to reset my El Capitan system as a development machine again.
I bought my license for BBEdit 11.5, so I installed that. I’ve used Visual Studio Code at work. I like how the window can take over the entire screen, but I don’t like how only three tabs for files are allowed per window. If you need more files open, you need to open another window. It seems weird. I’ve used TextMate. Again, I like how tabs are used to show files instead of the list used by BBEdit. I’m used to BBEdit’s quirks, so I’ll go with that for the moment
I need to reload Apache. I use the standard setup:
sudo apachectl start
However, Apache would not start this time. Running
shows an error with something called LockFile.
After some searches with StackExchange, I find out that LockFile is an Apache directive active for Apache <= 2.2. El Capitan runs Apache 2.4.16. Comment out the section that includes the LockFile directive and restart Apache. Localhost is working again.
I’m using the instructions in this page to activate Apache and PHP. phptest.php works after restarting, but I have the PHP timezone problem again. I had to copy a php.ini file from the included php.ini.default, set the timezone to “America/Los_Angeles” and restart Apache. Problem solved. More stuff coming soon.
My machine crashed again last night. It’s a Mac Pro and is connected to a battery backup that then goes to wall power. Last night, I heard the battery backup emit one beep, then shut everything down connected to it. I was running late and it was the end of the day, so I let it go to review in the morning.
Next morning, I can’t get the tower to boot. I disconnect it from the battery and try again with the same result. I disconnect it from the wall and start a support ticket. A few hours later, support comes by and the machine boots up. Their guess is that the capacitors inside the power supply need to discharge completely to avoid interference in the boot process. I’ve never heard of this before, but I do know that Apple has had capacitor problems in the past. This behavior matches what happened in the summer. Machine failed to start after shutdown. Machine was eventually disconnected from wall power. Machine boots again.
Very strange behavior, but I may be forced to disconnect the power if this keeps happening. I’ll need another machine, but I don’t expect one from work, due to other issues. I’ll figure something out.
Today’s news about a bash bug has sparked the internet equivalent of lots of people yelling about something they don’t really understand. I will admit that I don’t fully understand the bug, but I stumbled across a good explanation of the bash bug here.
UC San Diego computer security has also reviewed the infection vectors. They say that Apache modules (mod_php, mod_perl, mod_python) don’t appear to be vulnerable. However, the article linked above does say that library calls created by php functions may be vulnerable. I don’t know enough to understand how the module can be OK, but the system call going through the module is not OK. The key appears to be sending a hyperlink that opens a terminal window that then acts on the original bug. Seems like a lot of work, but it’s a hole. An easier possibility would be to attack apache systems that use CGI directly.
The installation of patches is recommended. When Apple and OS X gets patched is unknown. Red Hat rolled out an incomplete patch earlier today. It’s been reviewed and a better patch is expected soon.