The Illustrated TLS Connection: Every Byte Explained
The Illustrated TLS Connection
Every byte of a TLS connection explained and reproduced.
tls  networking  https  ssl 
Repeat yourself, do more than one thing, and do more than one thing — programming is terrible
If you ask a programmer for advice—a terrible idea—they might tell you something like the following: Don’t repeat yourself. Programs should do one thing and one thing well. Never rewrite your code from scratch, ever!.

Following “Don’t Repeat Yourself” might lead you to a function with four boolean flags, and a matrix of behaviours to carefully navigate when changing the code. Splitting things up into simple units can lead to awkward composition and struggling to coordinate cross cutting changes. Avoiding rewrites means they’re often left so late that they have no chance of succeeding.

The advice isn’t inherently bad—although there is good intent, following it to the letter can create more problems than it promises to solve.

Sometimes the best way to follow an adage is to do the exact opposite: embrace feature switches and constantly rewrite your code, pull things together to make coordination between them easier to manage, and repeat yourself to avoid implementing everything in one function..

Repeat yourself, but don’t repeat other people’s hard work. Repeat yourself: duplicate to find the right abstraction first, then deduplicate to implement it.

With “Don’t Repeat Yourself”, some insist that it isn’t about avoiding duplication of code, but about avoiding duplication of functionality or duplication of responsibility. This is more popularly known as the “Single Responsibility Principle”, and it’s just as easily mishandled.

Gather responsibilities to simplify interactions between them

The only real difference between pushing something together and pulling something apart is that some changes become easier to perform than others.

The choice between a monolith and microservices is another example of this—the choice between developing and deploying a single service, or composing things out of smaller, independently developed services.

The big difference between them is that cross-cutting change is easier in one, and local changes are easier in the other. Which one works best for a team often depends more on environmental factors than on the specific changes being made.

Although a monolith can be painful when new features need to be added and microservices can be painful when co-ordination is required, a monolith can run smoothly with feature flags and short lived branches and microservices work well when deployment is easy and heavily automated.

Modularity is more than reducing things to their smallest parts.

A layer of small components with no shared features creates a need for a layer above where these features overlap, and if absent, the user will create one, with bash aliases, scripts, or even spreadsheets to copy-paste from.

Even adding this layer might not help you: git already has a notion of user-facing and automation-facing commands, and the UI is still a mess. It’s always easier to add a new flag to an existing command than to it is to duplicate it and maintain it in parallel.

Similarly, functions gain boolean flags and classes gain new methods as the needs of the codebase change. In trying to avoid duplication and keep code together, we end up entangling things.

Although components can be created with a single responsibility, over time their responsibilities will change and interact in new and unexpected ways. What a module is currently responsible for within a system does not necessarily correlate to how it will grow.

Modularity is about limiting the options for growth

A given module often gets changed because it is the easiest module to change, rather than the best place for the change to be made. In the end, what defines a module is what pieces of the system it will never responsible for, rather what it is currently responsible for.

This means recognizing which bits are slightly more entangled than others, knowing which pieces need to talk to each other, which need to share resources, what shares responsibilities, and most importantly, what external constraints are in place and which way they are moving.

In the end, it’s about optimizing for those changes—and this is rarely achieved by aiming for reusable code, as sometimes handling changes means rewriting everything.

Rewrite Everything

The reason rewrites are so risky in practice is that replacing one working system with another is rarely an overnight change. We rarely understand what the previous system did—many of its properties are accidental in nature. Documentation is scarce, tests are ornamental, and interfaces are organic in nature, stubbornly locking behaviors in place.

If migrating to the replacement depends on switching over everything at once, make sure you’ve booked a holiday during the transition, well in advance.

Successful rewrites plan for migration to and from the old system, plan to ease in the existing load, and plan to handle things being in one or both places at once. Both systems are continuously maintained until one of them can be decommissioned. A slow, careful migration is the only option that reliably works on larger systems.

The reason we say “Never Rewrite Code” is that we leave rewrites too late, demand too much, and expect them to work immediately. It’s more important to never rewrite in a hurry than to never rewrite at all.

null is true, everything is permitted

The problem with following advice to the letter is that it rarely works in practice. The problem with following it at all costs is that eventually we cannot afford to do so.

It isn’t “Don’t Repeat Yourself”, but “Some redundancy is healthy, some isn’t”, and using abstractions when you’re sure you want to couple things together.

It isn’t “Each thing has a unique component”, or other variants of the single responsibility principle, but “Decoupling parts into smaller pieces is often worth it if the interfaces are simple between them, and try to keep the fast changing and tricky to implement bits away from each other”.

It’s never “Don’t Rewrite!”, but “Don’t abandon what works”. Build a plan for migration, maintain in parallel, then decommission, eventually. In high-growth situations you can probably put off decommissioning, and possibly even migrations.
dry  srp  programming  bestpractices  refactoring  maintenance  modularity  onethingwell 
The Math behind Project Scheduling, Bug Tracking, and Triage | USENIX
Many projects have poorly defined (and often overridden) priorities, hopelessly optimistic schedules, and overflowing bug trackers that are occasionally purged out of frustration in a mysterious process called "bug bankruptcy." But a few projects seem to get everything right. What's the difference? Avery collected the best advice from the best-running teams at Google, then tried to break down why that advice works—using math, psychology, an ad-hoc engineer simulator (SimSWE), and pages torn out of Agile Project Management textbooks.

We'll answer questions like:

• Why are my estimates always too optimistic, no matter how pessimistic I make them?
• How many engineers have to come to the project planning meetings?
• Why do people work on tasks that aren't on the schedule?
• What do I do when new bugs are filed faster than I can fix them?
• Should I make one release with two features or two releases with one new feature each?
• If my bug tracker is already a hopeless mess, how can I clean it up without going crazy or declaring bankruptcy?
project_management  software  estimation  agile  kanban  bug_tracking  bestpractices  is:video 
A How-To Manual for Fixing Badly Planned Cities - CityLab
If nothing is close to anything different, and the only connection is a single fat roadway, then the population is automatically conscripted into driving.
zoning  urbanplanning  urbanism  cities  cars  design  cycling 
2 days ago
This Stumbling Deer’s Hooves Sound Like Phil Collins’ Drum Fill on "In the Air Tonight"
This deer stumbling through a children’s play set sounds just like the drums in In the Air Tonight (you know the ones).

this is so good
is:video  deer  music  humor 
12 days ago
Long-Lived macOS
Yesterday, Uluroo started a Twitter thread about the old and forgotten features of macOS that have stood the test of time. John Gruber retweeted the thread, and it got a veritable explosion of replies containing tips, tidbits, and advice.

This article is a compilation of the best ones.
osx  macos  shortcuts 
13 days ago
IntelliJ IDEA 2018.3 Early Access Program is open! | IntelliJ IDEA Blog
New Search Everywhere & Run Anything dialogs seem like awesome improvements. Can't wait to try them.
5 weeks ago
[all variants] Difference between sudo su and sudo -s
corrupted by user's
HOME=/root uses root's PATH env vars
sudo -i Y Y[2] N
sudo -s N Y[2] Y
sudo bash N Y[2] Y
sudo su Y N[1] Y

[1] PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
probably set by /etc/environment
[2] PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin
The bottom line, is "sudo -i" is the proper command to run when you want a root shell that is untainted by the user's environment.
sudo  sysadmin  linux 
6 weeks ago
Building websites for Safari Reader Mode and other reading apps.
Alternate reading modes offer users improved readability and options for personalisation — people can choose to use these tools for any number of reasons including better accessibility with improved contrast, or enjoying the aesthetics of a low noise environment to read in.
I went on a bit of a journey exploring how our websites are experienced across these technologies and how we can make sure that our content is interpreted the way we want, regardless of how people are consuming it.
For demo purposes let’s look at what a simple HTML page looks like in Instapaper, Pocket and Safari’s Reader mode and compare <div> only content and semantic HTML.
instapaper  browsers  web  html  reading_mode 
6 weeks ago
Web Reading Mode: Determining the main page content - Ctrl blog
It hasn’t always been the case, but web developers today can expect that their web sites will look and behave mostly the same across the different standards-compliant web browsers. There is good and plentiful documentation for the standard web however this isn’t at all the case with reading mode. This is where I wish I could write-up a neat summary of how the different reading mode parsers (see table in part one) actually detect the main content of the page and provide some useful guidelines into how you can ensure your pages are compliant. Unfortunately, there is no neat summary or guidelines to work from besides the following algorithm:

All the different reading mode parsers try to identify an HTML element that contains a significant portion of text at nearly the same depth in the Document Object Model (DOM). Each node in the DOM is scored and evaluated against a varied set of criteria. Generally, nodes with little textual content or that consists mostly of links may be ignored entirely (including illustrations and tables). The exact criteria vary greatly from parser to parser.

The exact text selection algorithms are complex and varies from implementation to implementation. E.g. Mozilla Readability evaluates and scores candidate DOM nodes based on the total number of characters in each node and how many commas (,) there are in the complete text. Mozilla Readability makes some assumptions here about the average length of a paragraph of text, and the use of commas that don’t hold true in every text or in every language. I’ll get back to this in the next section. Maxthon Reader and Safari Reader works the same way, but adjust the scores significantly based on whether the content is actually visible on screen at the moment the reading mode button is pressed.
web  browsers  reading_mode  instapaper  html 
6 weeks ago
Fitbit's 150 billion hours of heart data reveal secrets about health
For something as important as heart health, it’s amazing how little you probably know about yours.

Most people probably get their heart rates measured only at doctor visits. Or maybe they participate in a limited study.

But modern smartwatches and fitness bands can track your pulse continuously, day and night, for months. Imagine what you could learn if you collected all that data from tens of millions of people!

That’s exactly what Fitbit (FIT) has done. It has now logged 150 billion hours’ worth of heart-rate data. From tens of millions of people, all over the world. The result: the biggest set of heart-rate data ever collected.
health  heart_rate  exercise  fitbit 
6 weeks ago
Google SRE book
I like this book a lot. If you care about building reliable systems, reading through this book and seeing what the teams around you don’t do seems like a good exercise. That being said, the book isn't perfect. The two big downsides for me stem from the same issue: this is one of those books that's a collection of chapters by different people.
sre  engineering  google 
7 weeks ago
switching.social: "Welcome new people! :blobcheer: 👏 👋 Some useful…" - Mastodon
Welcome new people!

Some useful #Mastodon features you might not know about:

Delete & Redraft - Click on the ... under your posts.

Tools to move instances - https://octodon.social/@schlink/100561221036847897

Block particular instances -

Image Descriptions - https://mastodon.social/@LiamErven/100549775260499384

RSS Feeds - https://mastodon.at/@switchingsocial/100368443255001645

Undocumented keyboard shortcuts - https://tootplanet.space/@YacYac/100551003949156532

Don't need link shorteners - https://
8 weeks ago
Let it Rip | Indie Stack
Ideally we could set a breakpoint on the very line of code that causes this console message to be printed. This can be surprisingly difficult though. There have always been a variety of logging mechanisms. Should you set the breakpoint on NSLog, os_log, printf, fprintf, or write? I could probably figure out a comprehensive method for catching anything that might write to the console, but am I even sure this console method is being generated in my app’s main process? There are a lot of variables here. (Hah! In this particular case, I ended up digging deeper and discovering it calls “CFLog”).

This is a scenario where combining lldb’s powerful “regular expression breakpoints” and “breakpoint commands” can help a great deal. Early in my app’s launch, before the warning messages are logged, I break in lldb and add a breakpoint:
xcode  lldb  debugging  breakpoints 
8 weeks ago
Bike Racks in Ann Arbor · Chris Salzman's Website
I look at this like the ice sculptures that pop up on main street every year: it’s a great thing that a business pays hundreds of dollars for once a year and is extremely temporary. What if for $1000 a business could fund the cost of a rack that has a plaque on it all year round?
friends  annarbor  bikes  cycling  infrastructure  design  urbanism  art 
9 weeks ago
An iOS alert view with a text field and a “smart” OK button – Ole Begemann
I wrote a handy little snippet for creating a UIAlertController with a single text field to request an input from the user. Its main feature, beside a slightly nicer API: you can optionally specify to disable the OK button when the text field is empty.
uialertcontroller  ios  uikit  lang:swift 
9 weeks ago
« earlier      
373proj a2council accessibility affordability algorithms america android animation annarbor api apple applewatch appstore art async autolayout aviation bash bestpractices business c c++ charting ci clang cli clips clojure cocoa cocoa_touch cocoapods coffee color complexity concurrency coreanimation coredata cryptography cs css culture cycling d3 data debugging dependency-injection design designpatterns detroit development diversity diy dmx512 documentation economics elecdiy electronics embedded encryption engineering english enum error_handling extensions facebook filetype:pdf finance flying foia font friends functionalprogramming game gcd generics gif git github golang graphics health history housing html html5 http humor icons inspiration internet interop ios ios10 ios7 ios8 ios9 is:gist is:repo is:tweet is:video java javascript journalism jquery json kvo lang:swift layout life lighting linux management markdown matlab media:document memorymanagement michigan mocking music mvvm networking newspapers nginx notifications nsa nsurlsession nyc nytimes nytnow objective-c oop option_type osx parser performance photog photography politics privacy productivity programming protocol_extensions protocols python quote radio reactivecocoa reactiveprogramming reactjs reactnative refactoring reference resources rest ruby rust_lang rx safety search security simplicity society software software_architecture solid ssl startups strings swiftlang sysadmin taxes tdd testing tls tool tools transit travel tutorial twitter types ui uicollectionview uiimage uikit uitableview uiviewcontroller umich unicode unix urban_development urbanplanning ux via:andrewsardone via:androidweekly via:cdzombak via:iosdevweekly via:mattb visualization watchkit water weather web_dev windows wordpress work xcode xctest zoning

Copy this bookmark: