DEV Community: Paul Seal

How to get realtime notifications for website traffic using Google Analytics and JavaScript

Paul Seal — Tue, 16 Jul 2019 22:03:34 +0000

I love stats

If you are like me, then you will also be fascinated in the visitor stats to your website. You will get excited when there are more than a certain number of visitors to your site.

You might spend a while looking at the realtime stats watching it, waiting to see the numbers go up. You might miss it when there are a lot of visitors to your site and you might wish there was a way you could be notified of a large volume of users on your site in realtime.

Well with this code you can set it up to send you a notification when the number of realtime visitors gets to the amount you are interested in.

Using Google Analytics Realtime Metrics

With this code, you can open up google analytics, go to the realtime overview page, right click on the realtime number of visitors and click on inspect. Then go to the console tab and paste in this code. You will need to replace the slack webhook url with your own.

Give me the code

(function checkStats() {
    var threshold = 10;
    var waitTimeInSeconds = 30;
    var number=document.getElementById("ID-overviewCounterValue").innerHTML;
    if(number > threshold) {
        var url = "https://hooks.slack.com/services/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"; //replace this with your slack webhook url
        var text = "There are " + number + " visitors on the site right now.";
        $.ajax({
            data: 'payload=' + JSON.stringify({
                "text": text
            }),
            dataType: 'json',
            processData: false,
            type: 'POST',
            url: url
        });
    }
    setTimeout(checkStats, waitTimeInSeconds * 1000);
})();

Registering for your WebHook Url with Slack

Click here to set up an incoming WebHook

Sign in to Slack
Choose a channel to post to
Then click on the green button Add Incoming WebHooks integration
You will be given a WebHook Url. Keep this private.

Make sure you replace the url in the code with your slack webhook url

Too many notifications?

Edit the threshold number and the number of seconds to suit your site volume and frequency of checking.

If it annoys you, just refresh the page and repeat the steps and edit the threshold and seconds to do the check less frequently.

Chrome Extension?

You might be thinking this should be a chrome extension. There are already some out there, some are free and some are paid for. I just wanted to get something simple that works for me. Feel free to take my code and use it in a Chrome Extension, but if you do, please make it a free one.

Find out how my dev blog reached 1 million page views

Paul Seal — Sun, 09 Jun 2019 06:14:40 +0000

In this post I will tell you how my blog reached 1 million page views.

Where it all began

I began blogging for 3 main reasons:

To create a personal brand for myself and help boost my career
I wanted to share useful tips and tools that I had learned as a web developer
I wanted to use Umbraco CMS as a content editor instead of just as a developer

I only realised how useful having a blog could be when I listened to John Sonmez's book Soft Skills. He tells you how important it is to have a personal brand. Whether you are looking to change jobs right now or not, you should be marketing yourself. As a developer, one of the best ways to do this is by having a blog. There is so much good advice in this book, I always recommend it to people.

If you're like me and prefer to listen to the audio version of a book, it is also available on Audible. That's how I "read" it.

John's advice was so valuable to me. I started writing blog posts, trying to be helpful to others. Whenever I came across a problem and it was painful to solve, I would create a blog post about it to save other people from that pain and make it easier for them.

My first lucky break

After about 4 or 5 months of creating articles and not many people reading them, I was inspired on my lunch break at work to write a post called 10 golden rules for becoming a better programmer. I had heard that list style posts were popular and opinionated posts seemed to divide people so that people who liked it shared it and those who didn't like also shared it, even just to tell people that they disagreed with it. Anyway this post was a bit of a hit with the programming community. I put it on social sites like facebook, twitter and LinkedIn Groups. I also shared it on Hacker News which was a good move because it stayed on the front page for most of the day. In one day that post got nearly 14,000 page views and within the space of a week it had around 25,000 page views.

Lots of people were linking to this post from their websites, sharing it on twitter, facebook and LinkedIn and even including it in their programming email newsletters. Because of this it helped my google SEO ranking a lot. Even though the traffic died back down after the first week, google was starting to send traffic to my site for this article and some of my other ones too.

List posts do well

Following on from the success of my 10 golden rules post, I realised that list post do well, so I started to think of other posts I could write:

These posts generated quite a bit of traffic, but it was nothing like the traffic I saw from the 10 golden rules article. I wanted that feeling of excitement again. I was chasing it.

I was driving the traffic manually

Because I wanted to see a lot of traffic to my website, I was sharing the articles everywhere. At the time, the most effective place to share them was in the LinkedIn groups. The .NET Developers group has 300k members. Even if people didn't like my post, they would comment on it and it would keep it at the top of the group, which sent traffic to my site when they clicked on it. This wasn't sustainable. People would get bored of seeing my articles at the top of these groups. I was pushing it down their throats. The traffic needed to be organic instead.

In the first year, only 7.9% of traffic to my website was organic and 62.1% was from Social sites.

I need to focus on creating good content that people want to search for, not gimmicky content of lists, or posts which polarised opinions.

They weren't useful to the reader, they just got people clicking through from reddit etc.

Getting more technical

I started to write more tutorial based blog posts. Ones which helped solve a problem for people rather than just gave me the immediate page view numbers in Google Analytics.

In my second year of blogging, it was the more technical posts like these which did well:

They were solutions to problems I had myself and other people were searching for solutions too.

So in my second year of blogging, 56.8% of page views were from organic search.

Be consistent

John Sonmez said if you are going to write a blog, you need to create at least one post per week, be consistent with it, have a regular day when your posts are released. This helps to create a following.

I would say I was more prolific than consistent, but regular posts of at least one per week really helped when it came to organic search.

This chart shows you the organic traffic from the beginning until June 1st 2019 (3.5 years)

A redesign and a move to https

In early 2018 I changed the site to run over https, I was worried about messing it up and losing all of my organic traffic, but luckily I had put the correct rewrite rules in place to redirect the traffic to the https route.

I also dropped the www. off the front of the address to make it a shorter url. I was already having to put the redirects in place, I may as well take this opportunity whilst I'm at it.

My site was looking very bootstrap and not very modern. I wanted to buy a new premium theme that would look more professional so I did some research and found that Creative Tim made the best looking premium bootstrap websites. I had to pay about $50 for the theme but it was worth it.

I don't know which of the above things was responsible, but my organic traffic just kept growing and growing from then onwards. See from 2018 onwards on the above chart.

Don't go changing

I daren't change anything at the moment. SEO seems to be working perfectly for me. I only include the meta description and meta keywords. I don't implement schema.org or anything.

I've just carried on writing posts to help people overcome errors that I was experiencing, such as:

I must be doing something right with these posts because google loves my site at the moment.

Here is a view of the last 3 months in Google Search Console

My top 10 pages

Summary

The main things that have helped my website get to 1 million page views are:

Don't give up
Be consistent
Solve other people's problems
Serve the site over https
Have a decent premium theme
Name the posts by what people would search for to find them
Use a decent content management system like Umbraco

A dinosaur ending

3 years ago, I wrote a post and made a video on How to find the hidden dinosaur game in Google Chrome. It was mildly popular at first but it soon died off. Just recently I have noticed it being a popular page again on my site. Here's the traffic for the post:

The 10 Commandments of Programming

Paul Seal — Sat, 11 May 2019 22:00:55 +0000

1. Thou shalt name things properly

As you probably know, naming things is hard, but it isn't impossible and as long as the name of the class, method, object or variable etc makes sense and helps the reader to understand what is going on, then you are doing it right.

Please don't be the person who does this:

var button1 = new Button();

var textBox3 = new TextBox();

Whilst the code itself may not be realistic, the point here is the lazy naming. It is not helpful to name somthing button1 or textBox3, give it a meaningful name.

2. Thou shalt not write obvious comments in the code

I personally think you shouldn't be writing comments in your code. I think you should write the code in a way which explains what it is doing itself without the need for comments. With that in mind, this commandment refers to those comments like this:

//get the user from the database
var user = GetUserFromDatabase();

//send an email to the user
var success = SendEmailToUser(user);

Those comments are just pointless. It is obvious what the code is doing there. If you really must write comments, use them to explain why you are doing something instead of saying what you are doing.

3. Thou shalt not commit secrets to open source code repositories

We all love open source software, and some of us even like to contribute to them or create our own repositories. We are good people, but don't be fooled, not everyone has good intentions, and some nasty people create bots to carry out their evil work.

You should never commit any keys or secrets to an open source repository because there are people who go through the commit history of public repositories looking for such things and using them for no good.

Use things like 'AppSettingsSecrets.config' locally that doesn't get checked into source control. You can use environment variables and key vaults too.

4. Thou shalt not duplicate code more than once

This might sound like a contradiction, but think about what it is saying. It says you can be forgiven for duplicating some code once in the same project, but if you need to duplicate it again for another part of the project then maybe you need to refactor the code so it can exist once and be called from all of the different places which need it.

5. Thou shalt not store passwords in the clear, or with a weak hash algorithm

This one is unforgivable. No one should be storing passwords as plain text in a database, or using weak hashing algorithms such as MD5.

If your data is breached, which is happening more and more it seems these days, you want to make it as difficult as possible for hackers. Ok so they managed to get hold of your data, but if you'd done things right, they wouldn't be able to access password and other personal data because you a very strong encryption method like AES 256 with a different salt and vector per record.

6. Thou shalt not steal other people's code

You need to be careful when using someone else's code. If you copy and paste it into your program, you need to be sure that you aren't violating any licences. You might think that you can just rename the namespace, classes and method names, but if the code still looks like the original, you can still be sued. There is a famous court case where Oracle who owns Java sued Google for copying its APIs.

There are so many different licences out there to understand, just because something is free, it doesn't mean you can do what you want with it. The GPL licence attempts to force people to release their source code which might be a problem if you are working on proprietary software.

This article will help you understand more about software licences.

7. Thou shalt not take on unnecessary dependencies

If you are a web developer, you have probably used jQuery at some point. Do you really need to use jQuery any more? How much of it are you actually using? If it is just to get elements by their class name or id, you can do all of that with vanilla javascript. Have a look at this website which tells you why you might not need jquery.

What about dates, do you really need to load in momentjs if you just want to format a date and time.

Surely the best thing to do, is find out the few lines of code you need in your project to achieve these things and eliminate these dependencies, unless you are using them heavily.

8. Thou shalt not write tightly coupled code

Tightly coupled code is code that can't be tested easily. It is code which depends on other code to be able to run. It reduces flexibility and re-usability of code.

Test Driven Development is a way of writing your tests first, then writing your code. You only write enough code to pass the tests. You write enough tests to make sure the code fulfills the requirements. If you are writing tightly coupled code it makes it harder to test. Following a TDD approach gets you thinking about how to write your code in such a way that it is not tightly coupled to any other code. You should use interfaces for your services and dependency injection to inject these services in to where you need to use them.

9. Thou shalt not swallow errors

Let's face it, we have all probably written a try catch statement where the catch just swallows the error so the application doesn't throw an error. This is bad, really bad.

You should at least be logging the error before swallowing it.

In an ideal world you will catch the error, log it, react to it with your code and throw it up to the next level where you can handle it appropriately there too.

10. Thou shalt not use hardcoded values

Please don't use hard coded values in your code. Come on, how annoying is that. If the value needs to change, what are you going to do, find and replace all occurances of "2"?

It is much better to use constants, variables or enums instead, where they have a meaningful name of what that value represents and you only have to update it in one place?

Want to have your say?

If you disagree or want to add any commandments, please either comment where you saw this post or tweet it with your comments and get the debate going.

The day I hacked Troy Hunt's website to delete my data

Paul Seal — Tue, 16 Oct 2018 22:50:01 +0000

Let's start from the beginning

I was listening to one of my favourite podcasts that morning, MS DEV Show. They interviewed Troy Hunt about internet security. Everything from password security to data breaches and even how IOT is now in adult toys. One thing that did pique my interest was the site which Troy has built to allow you to hack it. It's called http://hack-yourself-first.com It's got about 50 vulnerabilities and bad practices on it. He challenged us to try to spot the vulnerabilities and see if we could hack it ourselves.

Challenge accepted

I've not done much hacking myself, but I recognise that as a web developer I should know about the hacking vulnerabilities my sites could face. Therefore I need to be able to defend against them. Troy has a pluralsight course which guides you through all of the vulnerabilities in if you want to find out all of them.

Let's do some mob programming

I showed it to my colleagues and we had a team meeting to see what we could spot. We saw basic errors like storing passwords and emails as cookies, and changing url values to see other user details etc. I won't mention too many of them because I think it is valuable to go through it yourself. We were looking at it for a while and most of the vulnerabilities were pretty basic and we didn't think it reflected real life, but we have to remember that these are examples of the errors people really do make. We were at least pleased that our sites didn't have any of these vulnerabilities.

Here's where I went wrong

I was testing out the registration form so I put my name and work email address in and there wasn't a way to edit it in the user profile screen. I was able to hack the site to give myself admin permissions. I could see a full list of all users and their passwords, including mine. Which meant that other hackers could see my work email address too. I was worried it might make me a target to hackers. So it was in our interest to learn SQL Injection in order to remove the email address I had entered.

We needed to do some proper hacking

The only way we could think of removing my email address was by using SQL Injection. SQL Injection has been the top vulnerability in websites for a long time. Surely Troy must have left this site open to SQL Injection, otherwise what is the point to this site if it can't demonstrate the biggest problem. We weren't getting very far. We started by changing a URL to make it return all the results instead of just by the value in the query string. We tried several different variations and finally managed to get it to work, which meant we were in.

SQL Injection Example

This url uses SQL Injection to get all results

http://hack-yourself-first.com//CarsByCylinders?Cylinders=V6%27%20OR%201%3D1%20--%27

Now we can use SQL Injection, we needed to clear my data

To be able to update my email address, we first needed to know what the table was called. With a bit of SQL knowledge and googling we managed to get it to list out all of the table names in the database. This felt amazing. We were becoming l33t hackers. Next we needed to work out which table my email address was stored in. We tried a few of the membership tables but didn't get any luck with the username or email column. Then we realised it must be stored in the user profile table. We wrote a query to tell us what the column names were in the user profile table and sure enough it had an email column. Bingo. We wrote a query to update my email address to something different. It was such a good feeling when we queried the table to see the email addresses and mine was no longer there, but my new one was.

Okay what next?

Did we leave it at that? Of course not. When do you ever get the chance to break someone else's real website without them getting mad at you? After all that was his challenge. We tried to truncate and drop some tables and it didn't let us. So we changed to just deleting records. We managed to delete all records from the main table in the site. It worked. After that the data had gone. The site didn't work properly anymore and we felt so proud of ourselves.

Conclusion

This was a great team exercise to do as a group of developers. We all chipped in with ideas and we all learned a lot. You should definitely take a look at the site to see what vulnerabilities you can spot. I've purposely not given you the details on how we did what we did because it was a learning exercise and I think you won't learn if I just give you the answers. If you are struggling to spot the vulnerabilities or you want to find out how to do SQL Injection, you might want to do the pluralsight course, you can get a free 10 day trial.

10 golden rules for becoming a better programmer

Paul Seal — Wed, 11 Jul 2018 21:42:21 +0000

Here are my top 10 rules to follow which will enable you to become a better programmer

1. Don't repeat yourself

This is a great principle to follow. I really enjoy going back through my code after I have written it and refactoring parts that are used more than once. I get a buzz from reducing a long method down to several short methods. Ctrl+R+M works great in Visual Studio to help you refactor code into separate methods. This makes the code more reusable and testable.

2. Name your variables to say what they are for, not what data type they are

The only exception to this is if you are picking up someone else's code and are continuing with that, you should carry on with their naming convention.

3. Give your methods a clear name for what they are going to do.

If you do this well, it reduces the need for comments. You shouldn't need comments if your code is clear enough to read.

4. Don't use magic numbers or string literals

There shouldn't be any numbers or string values in your code that when someone comes to read later wonders what they are. Create constants, enums or private variables to give them a name so it is easier to understand.

5. Write your methods so they can be tested without having any dependencies on other parts of the application, where possible.

Write it in a way that it doesn't matter where it was called from. It makes the code far more testable and reusable.

If you are using session values or app setting values, pass them in as variables instead and get the session and config values at the point you call the method. This makes it far more testable.

6. Don't be afraid to ask for help

I'm not saying you should ask for help with everything and not learn for yourself, I mean have a good go yourself, but if you are stuck ask someone for help. They may have already had this problem and know how to solve it. Also the process of telling someone about what you are doing, what you are expecting and what the problem is, can bring you to solving it yourself.

7. Follow the boy scout rule

If you see some buggy or messy code, fix it while you are there and move on. Don't leave it for someone else to do, but don't rewrite the whole program either.

8. Share knowledge with others

Don't be selfish by keeping your knowledge to yourself. Try to create a culture of helping others. You'll find that you will work better as a team and you can help eachother to improve. You're not giving away knowledge and putting your job in danger if your colleagues improve. You are making yourself more valuable as you are someone who not only has the knowledge, but can also help other around them improve.

9. Don't interrupt your colleagues whilst they are in the flow

Think about it, when you are programming you have all of these pieces that you are putting together in your mind, like a house of cards you are carefully trying to build. If someone interrupts you to ask a question, then you lose concentration and that house of cards could easily fall down. It may take them 5 or 10 minutes to get that concentration and pieces back together in their mind, when you could have googled it or asked someone else. If you give your colleagues this respect and let them know, they will do the same for you, which in turn will make you more productive.

10. Use criticism as a positive instead of a negative.

To me, criticism is a chance for me to improve. If there is another way of doing something that I haven't thought of then I want to know about it as it will help me to improve.

5 things a developer should do before asking for help

Paul Seal — Tue, 10 Jul 2018 21:49:34 +0000

We all need help at times, but sometimes we ask for help too soon, or we just find it hard to ask for help

In this post I give you my opinions and experience about when I think you should ask for help, with a checklist of things you can do first before you do ask for help.

1. Debug

Please don't ask for help before you have tried to debug it yourself.

2. Check the logs

Check the application logs, web logs or even the System Event logs.

3. Isolate the code

Can you isolate the code and write a unit test for it? This will make fixing it a lot easier, because it makes testing it much quicker, and you don't have the overheads of an application needing to run, just to test a certain piece of code.

4. Google the error

Don't ask for help without googling the error yourself. You don't want the person to send you a 'Let Me Google That For You' link. Google is your friend, you should know how to use Google effectively to help you solve problems. Other people will have experienced the same problem and asked a question on sites like Stack Overflow or the ASP.NET forums. Make sure you search for the exact error message without your environment specific details. Look for recent results, and don't just copy and paste the code from somewhere unless you understand what it is doing. It is important that you understand what the problem was and how they solved it.

5. Find an example

Usually if you are struggling with something, you might find that the problem has already been solved in a different part of the application, or in a different application which you have the code for. Try looking for such examples to help you get through it without help.

Now you can ask for help

If you've done all of the above and you still need help then go ahead and ask. At least when you ask you won't come across as too lazy or inexperienced to try and solve it yourself.

If you work on your own or remotely and you have no one around to ask. Then isolate the code into a simple example console application or something and write a question on one of the helpful forums like Stack Overflow. All of the research you did above will help you write a good question so you don't get shot down.