This document now exists on the official ASP.NET core docs page.
- Application
- Request Handling
(EDIT: Besides Reddit, I've also put this up on Github Gist)
So while looking for information on security keys before getting one myself, I got very confused reading about all the different modes and advertised features of Yubikeys and other similar dongles. The official documentation tends to be surprisingly convoluted at times, weirdly organized and oddly shy about a few of the limitations of these keys (which I'm making a point of putting front and center). Now that I have one, I decided to write down everything I figured out in order to help myself (and hopefully some other people reading this) make sense of all this.
Since I'm partly writing these notes for myself, there might be some back and forth between "exp
| # Install and load required packages | |
| install.packages("needs") | |
| library(needs) | |
| needs(tidyverse, magrittr, animation, pdftools, png, scales) | |
| # Function that extracts data from Google Mobility PDFs | |
| process_google_mobility <- function(country_code, start_date, end_date){ | |
| # Convert first page of PDF into high-res PNG | |
| pdf_convert(paste0("https://www.gstatic.com/covid19/mobility/",end_date,"_",country_code,"_Mobility_Report_en.pdf"), format = "png", pages = 1, dpi = 300, filenames = "IMG1.png") |
| # Use this script to test that your Telegram bot works. | |
| # | |
| # Install the dependency | |
| # | |
| # $ gem install telegram_bot | |
| # | |
| # Run the bot | |
| # | |
| # $ ruby bot.rb | |
| # |
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
Sometimes you want to have a subdirectory on the master branch be the root directory of a repository’s gh-pages branch. This is useful for things like sites developed with Yeoman, or if you have a Jekyll site contained in the master branch alongside the rest of your code.
For the sake of this example, let’s pretend the subfolder containing your site is named dist.
Remove the dist directory from the project’s .gitignore file (it’s ignored by default by Yeoman).