I was fairly recently introduced to XUnit by a work colleague, and I now prefer it over the default Microsoft Unit Test project format. In fact, I feel kinda dumb for having used the default for so many years when there are so many alternatives, like xUnit, NUnit, and Moq. Granted I haven’t tried to use the other two, I thought I’d write about what I like about xUnit over the default MSTest framework.read more...
Well, since my last post on HTTPS I’ve gone and put an SSL certificate on my webserver and forced HTTPS for all connections to this site. I decided to do this tonight while I was doing some other poking around over SSH, and found that it was even easier to set up than I thought it would be. To accomplish this, I used Let’s Encrypt, which issues free SSL certificates so more websites can be served over HTTPS. For those not in the know:
Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit.
First of all, I headed over to the Getting Started page of Let’s Encrypt, which sends you to the certbot tool. From here, you choose a web server and an operating system and you are given detailed instructions on how to install the certificate. Basically, certbot fetches and deploys SSL/TLS certificates for your webserver, which you then set up your webserver to use. For example, this site is running on an Ubuntu DigitalOcean droplet with the ngnix webserver. I found the guide How To Secure Nginx with Let’s Encrypt on Ubuntu 14.04 extremely helpful to read through as well in this process, and it also gives you a link to the SSL Server Test which will let you know if you’ve done everything okay.
Overall, I found the process easy, and the guides and tools provided are top-notch. The people behind Let’s Encrypt have done a great job, and I’ll be recommending it to colleagues who are looking to do the same thing. You can now rest easy reading this blog and knowing it was written by me, Martin Brennan, and not the Illuminati injecting subliminal messaging driving you to BUY CONSUME REPRODUCE ▲.
Google Chrome has been steadily marching toward this end for some time now. From January 2017, Google will start flagging pages served over HTTP as Not Secure. The way that this will work in Chrome is that an indicator will be displayed in front of the address bar like they currently do with websites served over HTTPS with an invalid certificate. This will only be done on pages with credit card or password fields, which should have been served over HTTPS in the first place anyway. Firefox has already adopted this behaviour, and their main reasons for doing this, along with the Chrome team, is that it prevents MITM (Man in the Middle) attacks.
Though this approach is sound, today I was thinking about the impact this may have on regular users who may or may not be aware of the different indicators in the address bar, or be aware of the concept of HTTP/HTTPS or secure/insecure sites. Will they be alarmed that more sites suddenly have red “error” messages in the top bar? Will this behaviour, important though it may be, detract from even more pressing security issues, such as expired or invalid certificates, creating a “boy who cried wolf” situation? It would be really interesting to observe a regular user of Google Chrome and see what they do in these situations. Nevertheless I’m sure the Chrome team has thought of this, and will hopefully have helpful documentation for the lay-user.
I’m still not entirely sure that serving static sites, such as this blog, over HTTPS is worth it. I do not have any pages that accept credit card or password details. Though many would probably argue this point, and scold me for not realizing the importance of it, that my reliance on third party services like Disqus for comments and Google Adsense for ads would open up attack vectors if I serve my main blog as regular HTTP. I understand what proponents of making the web HTTPS are trying to achieve, to make passive eavesdropping by government agencies and malicious hackers much more difficult, and I do believe that at some point all pages will be HTTPS. As I saw it described today, if one person wears a mask they are still suspicious, if everyone wears a mask it becomes the norm. I just struggle to find time to set up an SSL certificate, though services like Let’s Encrypt may ease the pain of doing this, it’s just very low on my list of things to do. Though that platform is not without criticism, i.e. they do not offer free wildcard SSL certificates, I believe it is still a step in the right direction to get more people and websites onto HTTPS.
Google is also said to be pushing encryption as a factor in their PageRank algorithm, so it soon may become much more important to have a site served over HTTPS to stay relevant in search results. If anyone has any advice or thoughts on the matter, or whether it is important for me to do it on this blog, please let me know in the comments below!
I found a useful tool for profiling AngularJS applications last month, it’s called ng-stats. Here is what the tool is for, taken from the GitHub page:
Little utility to show stats about your page’s angular digest/watches. This library currently has a simple script to produce a chart. It also creates a module called angularStats which has a directive called angular-stats which can be used to put angular stats on a specific place on the page that you specify.
Here’s what it looks like when you run it using the bookmarklet:
The first number is the number of watchers on the page (including , $scope.$watch, etc.). The second number is how long (in milliseconds) it takes angular to go through each digest cycle on average (bigger is worse). The graph shows a trend of the digest cycle average time.
It’s really great to watch this while you click around your app to see where the hotspots are, and places where memory management could be improved. However, you should keep in mind that in-depth profiling will be required if you want to really see where the problem spots in your application are!
Just a quick tip if you ever need to implement paging in MSSQL. Here is a simple example of the query, which gets page x of size y and gets the total row count as well.
SELECT ID, Name, [RowCount] = COUNT(*) OVER() FROM MyTable WHERE Name LIKE '%Example%' ORDER BY ID OFFSET @Page ROWS FETCH NEXT @PageSize ROWS ONLY
This must be used with an
ORDER BYclause. The
@PageSizedetermine which set of records are returned out of the total result set.
I came across this subtle gotcha related to an ng-options option being undefined on select the other day at work. The initial problem was that out of a list of over a hundred or so options, one of them would cause the required form field validation to kick in because it was undefined on select. I eventually tracked it down to an issue deep within Angular’s options code, and the problem was actually nothing to do with Angular itself.read more...
I came across this Gist on how to create share buttons with just URLs while converting my blog to Jekyll, which is what I use at the start of each post:
It shows how to create Facebook, Twitter, Google Plus, Linkedin, Pinterest, Tumblr links. Scroll through the comments on the Gist to see the updated sharing links.
This blog is now run on Jekyll, and here’s why.
I got real tired of WordPress for the following reasons:
- It’s slow, for a simple blog.
- Reliance on a database.
- General heavy-ness. I didn’t really use most of its features, and it felt slow to navigate around the admin area.
- Did I mention it’s slow?
I’ve toyed with the idea of moving this blog to Jekyll for a few years now but I felt like it wasn’t mature enough to handle the transition yet. I had fears and doubts about how it would handle SEO and analytics and whether I would lose any important functionality from plugins. Nothing could be further from the truth. Jekyll is now a robust tool for blogging or documentation, and is great for you if you like having more control over the format and output of your blog. I’ve compiled all of the helpful links I found when making the transition.read more...
I noticed frequent slowdowns on my new work PC with Windows 10, an i7 and 16GB of RAM, and opened up Task Manager to see what could possibly have been slowing everything down. To my surprise, I found that the node process was hogging between 25 and 50 percent of CPU while it was running.read more...
Today NPM has made some important changes to their unpublish policy to avoid embarrassing fiascos like the one last week. You can read about the new policy here:
These changes are clearly a step in the right direction and should prevent an individual from breaking the entire NPM ecosystem by removing a package that is depended on by many others.read more...
|1 // 8||Next >>|
Want to read regular updates? Subscribe via RSS!