DakuTree

#!/usr/bin/perl -w

use File::Copy qw(copy);
use DBI;
use Win32::API;

use strict;
use warnings;

print ("Decrypting cookies...\n") && &fix_cookies && print ("Cookies decrypted!\n");

DakuTree

{
	//This method uses PHP to copy/rename files.

	"require": {
		//...
	},
	
	//List the files to copy/rename here.
	"vendor-copy": {
		"file/to/move/example.txt"            : "location/to/move/to/example.txt",

DakuTree

<?php defined('BASEPATH') OR exit('No direct script access allowed');

/*
	I wanted a single controller to handle my profile page, as well as any sub pages that may appear. At the same time, I wanted to avoid any possible code duplication.
	The code duplication appears when you want to validate the username passed by the URI. Each and every method would have to check this, and we can't just check this in __construct since the method would be called anyway.
	We could always do a redirect(), but honestly I don't think that feels right on a invalid profile page. I'd rather stay on the same URL and show an error.

	To get all of this done, we need to use _remap. _remap is called after __construct, but before the method. We can now have the construct validate the username & set the variable if exists, and remap only call the method if it does exist.
	If the username doesn't exist, the URI method is not called, and instead we call a fallback method.
	All of this omits the need to do any username validating within t

DakuTree

#!/usr/bin/perl -w

# Recently I've noticed twitter randomly removed some of the people I follow for no reason. I created this as an easy automated way to track those changes.
# The idea is you run it once a day (via cron, task scheduler or other), and it compares against the list it saved the previous day. If there is changes, it emails you with the changes.

# NOTE: You may run into rate limitting issues if you are following say, 2k+ users. You shouldn't be following so many people though, use lists!

#### MODULES ####
use Net::Twitter;
use File::Slurp;

DakuTree

#Based off https://gist.github.com/DakuTree/98c8362fb424351b803e & pieces of https://gist.github.com/jordan-wright/5770442
from os import getenv
from shutil import copyfile
import sqlite3
import win32crypt #https://sourceforge.net/projects/pywin32/

# Copy Cookies to current folder
copyfile(getenv("APPDATA") + "/../Local/Google/Chrome/User Data/Default/Cookies", './Cookies')

# Connect to the Database

DakuTree

#There is probably a much better way of doing all this, but this is the only time I've ever used Ruby
# Any suggestions/improvements are greatly appreciated.
require 'find'

Jekyll::Hooks.register :site, :post_write do |site|
	root_dir = "#{site.source}/_root"

	Find.find("#{root_dir}").select do |filename|
		filename = filename.gsub("#{root_dir}/", "")
		path     = "#{root_dir}/#{filename}"

DakuTree

# Jekyll - Custom post_file_link tag plugin. Points to /files/:title/FILE.ext
#
# How to install: Drop this file in `_plugins`.
# How to use: `{% post_file_link FILENAME.EXT %}`

module Jekyll
  class RenderPostFileLinkTag < Liquid::Tag

    def initialize(tag_name, text, tokens)
      super

DakuTree

#!/usr/bin/env python3
# Example of using concurrent.futures with the Range HTTP header for faster downloading.
# This requires the server you are download from supports the Range header.
# Couldn't find any clear solution for how to do this, so I wrote one up myself.
#
# Here we are using equal sized chunks representive of `(chunkSize, _) = divmod(contentLength, CONNECTIONS)`
# In my own testing:
#  - Size =< 10MB~ is slower than a single connection.
#  - Size  > 10MB~ is faster than a single connection.
#

DakuTree

Had some trouble with this myself, so I thought it would be good to share my findings.

At work I'm currently managing a fairly large estate of websites. Ideally we'd have everything running TLSv1.2+, however there are various legacy applications which require TLSv1.0 due to various reasons.
Ideally we'd either upgrade said applications to support TLSv1.2, or get rid of them altogether, however it sadly takes some time for the gears to turn, so it isn't really an option.

Now the initial thought would be to just set the ssl_protocols setting on a per server basis. You can try this, reload Nginx and notice there is no change, despite no warning in reload (which should occur here).
Whatever ssl_protocols Nginx sees first, regardless of server, is what is used for all servers. There is a few similar settings where this is the case, however they are usually flagged as such on reload, this one is not.

From my research, there is three possible solutions to this.