"Important" in the sense that many IT organizations have predicated their data forensics and incident response capabilities on being able to intercept and analyze traffic at arbitrary points within their corporate networks.
That's not to say that those choices reflect good architectural design, to be sure quite the opposite. But like many things in enterprise IT risk management, it comes down to where you spent your money, and things like DoH/DoT force will force certain organizations to admit "a lot in the wrong place".
To be clear, I'm not asking for the ability to intercept DNS requests, or encrypted traffic, at all. I'm fine (and encourage) encryption on the wire. I'm just as happy to get the logs on the local system, and ship them off.
I think the arguments are that there's a degree of security through obfuscation by forcing everything over a single common port (443), the transmission integrity benefits of TCP versus UDP protocols, and maybe just the overall simplicity of HTTPS as a protocol.
Correct. TLS-wrapped protocols don't seek to offer anonymity of the source and destination. They're designed to protect the confidentiality and integrity of data in transit. The best tools we have for anonymity are things like onion routing.
> While the Linux project has been closely associated with me personally, partly due
to the name, I would like to make it very clear that the Linux operating system is
a huge project done co-operatively by lots of people all over the world.
Even if you discount all the user-level programs that are an integral part of any
running Linux system, just the kernel contains code from hundreds of people from
all around the world.
Thanks to all of you
A PhD is intended to demonstrate that a person is capable of pursuing a course of research within a field of study, and has a mastery of the existing knowledge and pertinent skills/methodologies.
Unfortunately, in some fields, the PhD has sadly become a form of lazy gatekeeping, and reimagining the PhD in those cases may just be a matter of waiting for the old guard to step down.
In some other fields, the PhD is probably ripe for reimagining, but "independence" might not be the right lens through which to think about it. For example, it would be exceedingly difficult for a would-be physicist to independently build a large hadron collider to do their research with. The institutions that make those sorts of resources even possible are inherently large/complex, and in those cases the PhD is a less sad and lazy form of gatekeeping (i.e., you need to do a set of progressively more complex stuff under the tutelage of someone more experienced before we let you touch all of our big expensive things).
In yet some other fields, which may be younger, have less of an established orthodoxy, and lower overhead to participate in (e.g., the economic/anthropological open source software type work the author does), it seems totally reasonable that a person could develop and demonstrate their knowledge, skills, and abilities on their own and without a formal course of study. In such fields, the concept of the PhD doesn't seem as ready for reimagining as it does retirement.
Is this approach materially different/more scalable than using the active record, ORM, and seed file patterns supported by popular MVC frameworks (e.g., like how Rails does it https://edgeguides.rubyonrails.org/active_record_migrations....)? Isn't the crux of all that to be able to source control and easily distribute schemas and data in a database agnostic way?
This was my same thought. Really impressive as an exercise to develop this yourself, but this is core functionality of a lot of ORMS. Rails' ActiveRecord is kind of the shining example of this, with it's `schema.rb` versioning file
This is more meant as something that supplements migrations, as a “time machine” of your database so to speak. You would run it before you do any kind of potentially destructive operation on your database, such as running or rolling back a migration. Not all migrations are reversible (for example, migrations that drop columns), so you cannot easily go back to before you ran that migration. It’s also convenient when you check out an older version of your code - you can just restore the database as it was at that point in time. You could run a command in a git hook to enforce saving a new version when you tag a new release for example. In any case, it makes your database less of a black box, and it basically becomes ok to destroy it - because you can so easily make a new snapshot and go back to how it was before.
But for data we can use the seed files and associated patterns, right? Since it's just text in those files, they're trivially checked into source control, diffed, distributed etc.
> Use these charts where the communication goal is to show intent or generality, and not absolute precision. Or just because they're fun and look weird.
I love the intent and execution behind this. The implication of imprecision in the underlying data through rough looking "hand drawn" charts and graphs is a really smart design hack.
If you haven't tried this, you should. The type of feedback you get is proportional to the fidelity of your mock up.
Do a high-fidelity, fully realized html mockup, and you're more likely to get feedback about the little details like fonts, colors, icons, spacing, wording and maybe minor tweaks to the layout.
Draw a really low-fidelity mockup with a sharpie or on a whiteboard, and you're more likely to have a good discussion about fundamental layout/concepts, overall approach, etc, without anyone getting hung up bike-shedding about the details.
I think a lot of this has to do with perceived effort: if people think you spent hours building it, they're less likely to suggest a change that would throw most/all of your work out. This doesn't mean you can't or shouldn't prepare ideas/drafts beforehand if you want to, nor that you shouldn't increase the fidelity as you iterate.
I've tried many tools for this, but personally all the best and most fulfilling [early] design discussions I've ever had involved standing around a whiteboard.
It had, in Expression (Blend?) but not every component had a draw-like component which made things a bit awkward. Or maybe I missed something. Anyway XAML is still my favorite UI platform, it’s sad Microsoft doesn’t make any effort to make it cross platform.
Neat to see that they started by interviewing a diverse subset of their engineers; that type of user-centric research is invaluable. Moreover, I wonder what of their methodology could be mapped to a live analysis of the code review conversation threads they're having via GitHub.
More than anything else, though, I'm curious where teams like this still go to buy those amazing Apple Cinema displays?!
That doesn't seem especially profitable nor a core competency of AMZN. When you see a store branded bottle of ibuprofen, it's just a re-label of their contract manufacturer's pills.
Yep. The AmazonBasics brand of aspirin may appear, but it will just be putting their label on the product manufactured by the companies already specialized to manufacture it (as is probably true with a lot of existing AmazonBasics products).
Agreed! I have a template built that allows me to spin up a basic web app with all my baseline common dependencies ready to go and a handful of little nice-to-haves in place and deploy to Heroku in well under an hour. I love Rails!
That's not to say that those choices reflect good architectural design, to be sure quite the opposite. But like many things in enterprise IT risk management, it comes down to where you spent your money, and things like DoH/DoT force will force certain organizations to admit "a lot in the wrong place".