stuff.seans.comSean's Stuff | Learning new software development technologies out loud

Sean’s Stuff Learning new software development technologies out loudHome About Index That Conference 2018 Post navigation ← Older posts Personal Software Development Practices Posted by Sean 2 Don’t fear the code. It’s just code. Never write (or copy) a line of code that you don’t fully understand. Figure out how things really work and why they work they way they do. If you don’t understand something, go deeper. Read the source code for the library you’re using. Use tools to figure out how things work–debugger, unit tests, sample programs. Create a punchlist to guide your work–investigations, things to do, things to test Test the hell out of your code. Be as thorough as possible When you get stuck, go for a 5 minute walk. When you get stuck, describe your stuckness out loud to somebody else. Write down what you’ve learned. Create a FAQ document and answer all the questions. Try to teach someone else what you’ve learned. Create a blog. Leave breadcrumbs for yourself and others–personal notes or comments in the code. Posted in Miscellaneous Feb · 06 That Conference 2018 – An Extended Explanation of Caching Posted by Sean 0 That Conference 2018, Kalahari Resort, Lake Delton, WI An Extended Explanation of Caching – Tom Cudd Day 3, 8 Aug 2018 2:30 PM Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers. Executive Summary A number of places where you can do caching Various tools for various places Really all about 1) populating, 2) invalidating Caching examples Network tab in browser, pages from memory or disk cache Content from CDN Special applications – e..g. Varnish WordPress plugin – specify cache settings for blog Caching is Like Regex If you’re not careful, you’re going to have new problems Application Architecture Christmas tree” showing server, cache servers, CDN, load balancers, etc. Problem Caching solves one problem–performance 3-sec rule: user leaves if something takes longer than 3 secs 40% of users leave Another reason Buy some time e.g. before application crashes Cost-benefit analysis–caching costs vs downtime Measure First User metrics Load times Site no crashing every 5 minutes S.M.A.R.T. Goals – specific measurable achievable relevant time-bound How to Not Suck at Caching Caching is additive Can’t just throw caching onto server that’s already overloaded Don’t over-engineer Use the simplest solution that satisfies the requirements Measure, change, test, measure Caching Doesn’t Help Oversaturation Network hardware Thread death–virus”, creating multiple threads for each request Thundering herd If you get large number of initial requests, a large number of them go all the way back to server, since it takes a little time to cache the data Lack of information Bad decisions End Users Browser Caching Setting request headers–page tells browser to cache a page Requires a hit to operating system Unique naming Rename an assets to force download of long cached object Set with Web Server E.g. est cache-control for certain pages External/Edge Services CDN – Content Delivery Network Point your URI to 3rd party server They then pull files, as needed, from your server Most big sites on the web run on CDN Improve page load time Serve request from server that has shortest travel time to client High availability Cached data could still be present even when your origin server hiccups Can maybe buy CDN servies at lower cost than scaling out actual servers CDN Features Setting TTLs, other configs based on extension Region, language routing Mobile detection WAF/Security Applications can do double duty–firewall + CDN DDOS protection CDN Providers Cloudflare Incapsula Cloud providers Akamai Fastly Akamai Match file extensions Honoe cache control of origin Can have configs for some stuff on your server Measure and Test Your Systems Don’t over-engineer–get strange results Spin up different instance if you need different purpose Varnish Separate servers Both memory and disk paging Web/App Layer Baked vs fried Building on demand vs preloading cache Cache gen’d on demand when request hits (fries) Preload cache ahead of time (baked) Disk vs memory Products Adobe Experience Manager Sitecore Prefetch, data, item, html caches Drupal Performance caching (SQL queries stored) Output Caching IIS- – generate on request App/Data Layer Reducing database calls Reducing API calls Ehcache Java based applications Memory or disk Memcached In memory, key/value store Reduce database load Not synchronized Scalable separately Let’s Not Fight Not worth arguing about which is better Memcached, Redis, Mongo All are good Database Redis Firebase Stored procedures – reduce network bandwith by calling short sproc rather than sending long query Challenges Invalidating stale data Caching Procedures Only two things you’ll really need to do with caching Populating Invalidating Debugging, need to remind people to clear their cache [Sean] But should users have to worry about this? If you need to have them clear cache, then something’s not working properly Populating Caches Pull based – cache tool pulls from your server Push based – your code has to push out data to the cache Cache clearing Staggered approaches Clearing individual items Using APIs and automation Posted in That Conference 2018 Tagged Caching Aug · 09 That Conference 2018 – Securing Your ASP.NET Core Applications Posted by Sean 0 That Conference 2018, Kalahari Resort, Lake Delton, WI Securing Your ASP.NET Core Applications – Cecil Phillip Day 3, 8 Aug 2018 1:00 PM Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers. Executive Summary Quick review of authentication pipeline Various options for authentication ASP.NET Core 2 Cross platform web framework Targets .NET Standard 2.0 Introduces Razor Pages SignalR Core available ASP.NET Core 2.1 out now Middleware Pipeline diagram Application Startup Startup.cs Configure takes IApplicationBuilder, IHostingEnvironment app.UserXyz, app.UsePdq The order of middleware matters HTTPS In VStudio, two servers IIS Express Enable SSL in properties Kestrel – cross-platform Have to use .NET CLI tool dotnet dev-certs https –trust Generates self-signed cert that’s automatically trusted This cert doesn’t appear in cert manager MMC – add snap-in, Certificates snap-in, My user account Now looking at certs for the current user only Now you see the dev cert that we just created When you run, you fire up 2 endpoints–HTTP, HTTPS–that it’s listening too Remove cert dotnet dev-certs https –clean Do not use this dev cert in production Only for local development Authentication Many options, i.e. middleware Cookies Twitter Google JWT Tokens Facebook OpenID Connect Microsoft Accounts Custom Windows Cookie Authentication Demo In ConfigureServices, services.AddAuthentication .AddCookie In Configure, do app.UseAuthentication Need to do this before UseMvcWithDefaultRoute Mvc is a terminating middleware”–stuff after it won’t run Controller code Login action, with LoginViewModel Create ClaimsIdentity with a Claim Pass in to HttpContext.SignInAsync Back in ConfigureServices .AddCookie takes opts with authentication events We can handle various events as part of pipeline Kick out existing logged in user Twitter Authentication Demo .AddAuthentication, AddCookie, AddTwitter (pass in client ID and secret) Still just do app.UseAuthentication in Configure SecretManager Manage user secrets Lives in app profile JSON data with different secrets, e.g. Twitter-ClientSecret (or) dotnet user-secrets Roaming, so it will...