epiphany27

Stop using JWTs!

TLDR: JWTs should not be used for keeping your user logged in. They are not designed for this purpose, they are not secure, and there is a much better tool which is designed for it: regular cookie sessions.

If you've got a bit of time to watch a presentation on it, I highly recommend this talk: https://www.youtube.com/watch?v=pYeekwv3vC4 (Note that other topics are largely skimmed over, such as CSRF protection. You should learn about other topics from other sources. Also note that "valid" usecases for JWTs at the end of the video can also be easily handled by other, better, and more secure tools. Specifically, PASETO.)

A related topic: Don't use localStorage (or sessionStorage) for authentication credentials, including JWT tokens: https://www.rdegges.com/2018/please-stop-using-local-storage/

The reason to avoid JWTs comes down to a couple different points:

The JWT specification is specifically designed only for very short-live tokens (~5 minute or less). Sessions

While a lot of Node.js guides recommend using JWT as an alternative to session cookies (sometimes even mistakenly calling it "more secure than cookies"), this is a terrible idea. JWTs are absolutely not a secure way to deal with user authentication/sessions, and this article goes into more detail about that.

Secure user authentication requires the use of session cookies.

Cookies are small key/value pairs that are usually sent by a server, and stored on the client (often a browser). The client then sends this key/value pair back with every request, in a HTTP header. This way, unique clients can be identified between requests, and client-side settings can be stored and used by the server.

Session cookies are cookies containing a unique session ID that is generated by the server. This session ID is used by the server to identify the client whenever it makes a request, and to associate session data with that request.

*S

Overview

Some notes about:

Explaining why current day Linux memory swap thrashing still happens (as of 2016).
Mitigating "stop the world" type thrashing issues on a Linux workstation when it's under high memory pressure and where responsiveness is more important than process completion.
Prioritizing and limiting memory use.
Older ulimit versus newer CGroup options.

These notes assume some basic background knowledge about memory management, ulimits and cgroups.

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

Clarify and agree on the scope of the system

User cases (description of sequences of events that, taken together, lead to a system doing something useful)
- Who is going to use it?
- How are they going to use it?

Requirements

no upfront installation/agents on remote/slave machines - ssh should be enough
application components should use third-party software, e.g. HDFS, Spark's cluster, deployed separately
configuration templating
environment requires/asserts, i.e. we need a JVM in a given version before doing deployment
deployment process run from Jenkins

Solution

PS: If you liked this talk or like this concept, let's chat about iOS development at Stitch Fix! #shamelessplug

Protocol-Oriented Programming in Swift

Speaker: David Abrahams. (Tech lead for Swift standard library)

"Crusty" is an old-school programmer who doesn't trust IDE's, debuggers, programming fads. He's cynical, grumpy.
OOP has been around since the 1970's. It's not actually new.
Classes are Awesome
- Encapsulation
- Access control

Getting Started with a library project in Android Studio

So we're working on creating Android Material Awesome, a library which will hopefully incorperate the benefits of Material Design, Twitter's Bootstrap, and FontAwesome. What we really wanted is a project other people can easily include into their projects using gradle dependencies. To do this we needed to create a standalone library project so we could make it as lightweight as possible for including as a dependency, and a sample app that would use it for testing. These are the steps we took to get started in Android Studio (version 1.1).

Create Projects

The first thing we needed to do was to create two new projects, with all the default settings (Blank Activity etc). One for our sample app, and one for our library. We added both of ours into the same GitHub repo, however you can save them wherever you like.

	# overwrite master with contents of seotweaks branch (seotweaks > master)
	git checkout seotweaks # source name
	git merge -s ours master # target name
	git checkout master # target name
	git merge seotweaks # source name

	/*
	* Copyright 2014 Chris Banes
	*
	* Licensed under the Apache License, Version 2.0 (the "License");
	* you may not use this file except in compliance with the License.
	* You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software