Forem: Valentine

How to use inline JavaScript with HTML? You definitely like really bad code

Valentine — Fri, 06 Apr 2018 18:08:06 +0000

I have made so many mistakes in my short coding lifetime to know never to use the DOM to call javascript methods like this:



<button type="submit" onclick="shoutout()">YAY!</button>

Doing that is just bad, really really bad. You should never do it. Never ever ever do it. In all honesty and fairness, your code will generally work the moment you do it and everything will be fine. But, the moment you make up your mind to optimize your page... Horrible stories will be told thereafter.

Few reasons to avoid inline Javascript temptation

I didn't even need to think too much about this. Just a quick search brought me a stackoverflow thread that highlighted a lot of my reservations for inline js and even more. I'd list them here

It's not recommended to inline your javascript since you can't cache them. You definitely know how much resources caches saves your client and how fast your website loads because of it. Don't sacrifice it.
Maintainability! How would you even begin to trace where you called javascript methods to start fixing it? How would you even keep track of what is using what?
Separation of concerns
Optimization and minification - I tried extracting the js files and minifying them, but the code never worked at all, which is why I am writing this.
Inlining does not have any direct performance gains compared to external scripts. However, when you talk about caching and running scripts after you have loaded the page, it begins to make sense why not to do it.

Ok. I think that's all I have off the top of my head. Now, read the full story of how I got to writing this.

My own horrible story

So, I met this cool project and liked the idea, so I jumped on it. It is in the fintech space and I have always loved money and fintech and money. I always wanted to know how all these things worked behind the scenes. So you can see how I jumped and accepted this with my two hands wide open when it was presented to me.

As I got working on the project, it turned out that there was a developer who attempted making it work before, but couldn't, so he bailed (I still can't see why). Apparently, some of the javascript code he wrote was still all over the place in the HTML pages. As a cool guy that I am, I did not mind that at all. I happily continued working on the project and learning how to use the code that way. I just have to mention here that class names and id names were completely obscure and undescriptive. I have a headache thinking about it right now.

I like to keep things clean, but only after getting it to work. I continued coding with my script just below the HTML as it was faster for me (which is perfectly normal by the way). When I finished getting everything to work, it was time to take all the Javascript out and put it in a separate file so I can minify it.

I minified it quite alright and some parts of the app were working while others were not working. I unlinked the minified version and linked the 'unminified' version and the page worked fine. I copied and pasted all it's content again and minified one more time and it still did not work again. Something was obviously not right.

I went through the page again and realised that when I minified the file, for some weird reason, every method that is called directly from the HTML as the example above somehow didn't exist anymore (well, it got minified obviously). I checked how many of such exists and I am certain I counted at least 10 before scrolling the page. There are multiple lines this way.

What I would do

The best thing to do is use event listeners for everything. This way, it wouldn't really matter how I minify it, everything would just work fine. I probably have like 10 pages to rewrite and use event listeners for, but that fine. Imagine you have to do this for an application with several times that amount of pages... Sheesh!!!

I'm already scared.

Wish me luck... I'd definitely be needing a lot of it.

PS: In a totally unrelated topic, please always indent your code properly and remove anything you commented out you no longer need. Take pity on the next dev who would work on it.

How to setup Nginx and PHP7.1 with FPM on Mac OS X without crying

Valentine — Sun, 29 Oct 2017 23:02:02 +0000

I had problems with my nginx for months. I read a ton of articles online but couldn't find a solution. Most of what I saw was for php7.0, and they used php-fpm-sock file which clearly does not exist in php7.1. Creating and configuring php7.1 to use the sock file was a different kettle of fish on it's own. I failed at it several times. When I upgraded to High Sierra (which basically wiped my system clean due to multiple failures), I had to start setup all over again. I decided to take my time and actually tackle this nginx setup issue. There was still no tutorial on it that worked for me. I made up my mind to figure it out on my own. Did I? This article will explain how I did it.

If you are new to http servers on your local machine, this article would make setting up nginx pretty easy for you even if you don't understand most of the stuff. If you use LAMP or WAMP or any of that, you might want to go read up on setting up nginx for your OS before coming right here. The nginx configurations would be the same. Just the folders to find the nginx.config file for nginx may change from OS to OS. Yes, this should work for non Mac users as well.

To make this article pretty useful to you, I'd skip a lot of stuff that are not the focus (stuff that there are probably like 1,000 articles on already). I'd speed through a lot of this. I use High Sierra on my Mac (I used Sierra before) so I cannot guarantee what would happen for other versions of macOS X. If you are following and anything is missing, do not fret. Just Google how to install it and then continue with this setup.

If you already have Nginx and PHP7.1 installed, you can skip to the installation section and head straight to configuration.

INSTALLATION

We are going to use Homebrew for all our installations. It makes life easy and it is pretty straightforward. Click here to read about it or just install right away.



/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

When you are done, ensure homebrew's environment is setup correctly.



$ brew doctor

Next we're going to install a launchctl wrapper that will stop, start, and restart any service we install with brew.



$ brew tap homebrew/services; brew tap homebrew/dupes

Let's install php7.1 with fpm and display the version after installation.



$ brew install php71 --with-fpm --without-apache; php -v; php-fpm -v

Start PHP right away.



$ brew services start php71

We would not have to setup much for PHP7.1 with FPM because it comes pretty configured right out of the box. Let's just get nginx and get the party going.



$ brew install nginx; brew services start nginx

We are done with installations for now, time for configurations. Nginx should be running on port 8080 if you also have apache installed and running. Either way, you should see which port it is running on after installation, so you can quickly visit http://localhost:8080 to see the default nginx homepage (use the port displayed in your terminal after setup instead, if it is not 8080).

THE CONFIGURATION

When installed with homebrew, Nginx’s configuration file would be found in /usr/local/etc/nginx. Open it with any editor you like (I use nano to save time).

We are going to leave everything the way it is and just edit only a few sections. The nginx.config file would be configured properly upon installation to serve static files. All your websites would be in /usr/local/var/www folder so that nginx can see them. Nginx mirrors all the files there to it's html folder that can be found in /usr/local/Cellar/nginx/[version_number]/html as of this writing. If you want to set a different part for your files, edit this block of the config file and set a different root.



location / {
            root   html;
            index  index.html index.htm index.php;
        }

Don't forget to add index.php to the index list so that nginx can automatically load that file when it serves your site.

The next thing is to setup how our php files are proxied for execution. Edit your block to match the following.



  # proxy the PHP scripts to Apache listening on 127.0.0.1:80
        #
        # location ~ \.php$ {
        #    proxy_pass   http://127.0.0.1;
        #}

  # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
        #
        location ~ \.php$ {
            root           html;
            include        fastcgi.conf;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            #fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
            include        fastcgi_params;
        }

I left the fastcgi_param line commented out just incase you need to set something there later. All params are already included below it and the fastcgi.conf file should have all the settings required to use php-fpm. Save your file and restart nginx.



$ brew services restart nginx

If you are using multiple configuration files (all stored in /sites-available), you would have to adjust them one by one as well. You can store this setup block above in a separate file and include it in all of them if they all use the same root folder.

Time to test our beautiful setup. Create an info.php file in /usr/local/var/www folder and put any php code of your choice that should output stuff (I echoed phpinfo()). Go to http://localhost:8080/info.php and it should display just fine (use the port displayed in your terminal after setup if it is not 8080).

Now buddy, go enjoy your nginx and cry no more.

NGINX is a free, open-source, high-performance HTTP server known for its high performance, stability, rich feature set, simple configuration, and low resource consumption. If you want to see how nginx performs in handling requests and heavy usage when compared to apache, read Web server performance comparison. If you would like to understand better about the individual strengths of nginx and apache, checkout this article on Digital Ocean.