atheken @ atheken @programming.dev

Posts

0

Comments

103

Joined

2 yr. ago

Well, a couple things:

My points are related to provable advantages to doing it while writing code. They’re also not argumentative.

Your points are related to a personal preference of aesthetic while reading code. They are not provable advantages. They’re also quite “ranty,” which is rarely a persuasive way to convince someone of your position.

If you actually want to get people to change their habits around this, I think you’ll have better luck with my approach than ranting about why you don’t like how it looks.

Along with this, once you’ve dealt with enough kinds of problems, you end up developing an intuition for how something was probably implemented.

This can help you anticipate what features are probably included in a framework/library, as well as how likely they are to work efficiently/correctly (you know that XYZ is a hard problem vs. ABC which is pretty easy for a journeyman to get right.)

As an example, a friend of mine reported a performance issue to a 3rd-party vendor recently. Based on a little bit of information he had on data scale and changes the 3rd-party made to their query API, he basically could tell them that they probably didn’t have index coverage on the new fields that could be queried from the API. That’s with almost no knowledge of how the internals of their API were implemented, other than that they were using Postgres (and he was right, by the way).

That’s not always going to happen, but there are just a lot of common patterns with known limitations that you can start to anticipate stuff after awhile.

I would recommend email for this. It’s a text-based protocol and the original RFCs 821/822 are pretty straight-forward. There are some additional rabbit holes related to content encoding, but if one can implement a simple MTA, a huge amount of the magic of the internet becomes accessible.

I would not recommend trying to build a “production grade” MTA, as there is a lot of minutia to get right, and it’s easy to screw up.

I agree with the need, but not your rationale, I’m in the “always curly braces” camp for two reasons:

• when a second line gets added in a condition block, the braces might not get added, a bug.
• one less decision to make while coding. Anything that removes trivial decision-making can speed up authoring and reading code.

Not at all! Glad it was something simple!

I believe the setting is user.email so maybe confirm that’s what you have set in both? Git will silently ignore settings that aren’t used/defined.

Your question, as best as I could tell, is that you want DNS traffic to exit through your VPS node, rather than your client machine.

I posited one reason this could be happening, and additionally, a similar setup that provably routes traffic through the VPN based on the method I described.

Nobody in here is obligated to help you, I gave you a couple threads to pull on to resolve your question, so maybe consider accepting it graciously, rather than being obstinate.

Of course, you have to trust that third party, which may/may not be prudent.

It’s not completely clear what you mean, but I’m guessing you’re only routing a subset of your traffic through wireguard, probably only IPv4, and there may be some IPv6 traffic that is not being routed over your wireguard connection.

You can specify any IPs you want for DNS with wireguard, and if your allowed IPs include those addresses, then it should flow over your VPN.

I do this with Pihole at home, and it blocks ads while I’m away.

With whatever test you’re running that says stuff is “leaking,” keep in mind that the website is going to report any traffic that originates from your VPS as “unprotected” because it’s not their system, and even if you run your own DNS server, it’s still got to query upstream to a public DNS. All they’re really doing is demonstrating which upstream DNS server you have configured, and it’s up to you if you want your VPS’s IP to be connected to the query history of that upstream DNS provider.

You will usually need a hostname in DNS for your VPN server to make it easy to find/connect, which will use your normal DNS resolution. Once connected, if you have it set up correctly, new dns queries should route through your VPN connection. Just keep in mind that various results can be cached on your system and in web browsers, so you should quit and reopen your browser after you connect to the VPN before you run your “leak” test.

LLMs aren’t going to give you a roadmap or prioritize concepts. They also frequently produce contradictory information.

They’re good tools if you already have some experience and vocabulary in the field, but a more structured approach to building some projects and acquiring skills is better.

In my 20 year career, I’ve never had a single position where I could ssh into my work machine from a remote location.

I would say that if you have been able to do that, it’s exceptionally rare, and there are a number of security red flags of your organization is allowing that.

And you can do the previous years of the coding challenge at any time.

I took some time off, and this was a good source of solving “real” problems, rather than trying to write something to optimize for l33tcode (which, is fine… just not a good measure for typical software engineering responsibilities, IMO).

Like I said in my other comment, I think people tend to lump all of MSFT's activities into the same bucket. DevDiv has always seemed pretty decent, and I am usually reminded of this comic when people talk about MSFT's "shady" activities.

Everything is temporary. If we were talking about a niche language, I might worry a little bit that it could just lose momentum and die. But TS is a juggernaut. The only way typescript “dies” is if JS integrates enough of its features to make it redundant.

Besides that, if Oracle managed to allow Java to continue to grow and flourish, I have confidence that MS can do at least that well. I also think lumping all of MS’s products into the same boat is a mistake. They have been pretty good stewards of their languages for decades.

It’s necessarily complexity that is easily encapsulated in methods.

If those methods are under test to verify their behavior, trivial typos can be detected instantly, without adding another dialect and more conceptual overhead to a project.

If those methods are not under test, then there’s a tiny bit of help by using a DSL if it can be compile-time checked.

I used to be full on the ORM train. Now I’m a little less enthusiastic. What I actually think people need most of the time is something closer to ActiveRecord. Something that can easily map a result set into a collection of typed objects. You still generally write parameterized SQL, but the work of translating a db decimal into the correct target type on a record object in your language is handled for you (for example). In .net, Dapper is a good example.

I also think most people overemphasize or talk about how other programmers “suck at SQL” waaayy too much.

IMO, for most situations, these are the few high-level things that devs should be vigilant about:

• parameterize all sql.
• consider the big-o of the app-side lookup/write methods (sometimes an app join or pulling a larger set and filtering in memory is better than crafting very complex projections in sql). This is a little harder to analyze with an ORM, but not by much if you keep the mappings simple and understand the loading semantics of the ORM.
• understand the index coverage of queries and model table keys properly to maintain insert performance (monotonically increasing keys).
• stop fixating on optimizing queries that run in a few seconds, a few times a day. Optimize the stuff that you run on every transaction - if you need to.

On most of those points, if you don’t have aggregate query counts/metrics on query performance on your clusters, starting to get cute with complex queries is flying blind, and there’s no way to prioritize what to optimize.

For the vast majority of cases, simple, obvious selects that don’t involve special db features are going to do the job for most applications. When the database becomes a bottleneck, there are usually much more effective ways to handle them than to try to hand optimize all the queries.

Lastly, I have a little bit of a theory that part of the reason people do/do not like looking at SQL in code is because it’s a hard context switch from one language to another, often requiring the programmer to switch to “stringly-typed” mode, something we all learn causes huge numbers of headaches in our first few months of programming. Some developers accept that there’s going to be different languages/contexts and not all of them are going to be as fluent or familiar, but accept that this is par for the job. Others recoil from the unfamiliar and want to burn it down. IMO, the former attitude is a lot more productive.

My running joke, after four different friends told me they were using ChatGPT to help them with it, is that the language is so hard to learn that we invented an entirely new class of AI to help.

It’s a joke, of course, but it does have some “surprising” syntax, since some stuff is whitespace sensitive, and there are subtle differences between () and [] and [[ ]], for example. All of that’s due to the long history of shell behavior, so I don’t necessarily blame bash.

Unicode is thoroughly underrated.

UTF-8, doubly so. One of the amazing/clever things they did was to build off of ASCII as a subset by taking advantage of the extra bit to stay backwards compatible, which is a lesson we should all learn when evolving systems with users (your chances of success are much better if you extend than to rewrite).

On the other hand, having dealt with UTF-7 (a very “special” email encoding), it takes a certain kind of nerd to really appreciate the nuances of encodings.