> turns a window into a base station that can be attached to a building window inside and turn the outdoors into a service area
You could easily enclose this by some architectural feature on the interior of the building or even use a window that's off the back of a maintenance closet.
I like what I'm seeing, though I'm not sure I have a use case. On a VPS, I'll typically run a cloudflared container and configure a Cloudflare tunnel to that VPS. Then, I can expose any port and point it to a subdomain I configure in the CF dashboard. This gives https for free. I can expose services in containers or anything else running on the VPS.
I'll concede there's probably a little more hands on work doing things this way, but I do like having a good grip on how things are working rather than leaning on a convenient tool. Maybe you could convince me Sidekick has more advantages?
I think DRY should be supplemented by "Don't make me read it multiple times". Repeat yourself, by all means, if that makes it so that I don't get all twisted up jumping between so many files that I can't keep the main thread straight while I read your code.
I find his stuff sloppy and uninteresting, too, and he has no charisma. This just goes to show that he really does know what he's doing. He identified the statistically meaningful things to focus on and perfect. Imagine if he was just the producer for someone who actually gave a crap about making quality content.
Partly, I think that the culture is more affected by the lack of history than most people realize. If you've lived in Europe, and I'm sure elsewhere, you understand your mortality implicitly from the centuries-old buildings and streets. At least that's what I got out of it.
The post is silly because you wrote software that makes use of argv[0]? On the contrary, it opens a discussion about unintended security implications that might be avoided in the future if command line implementation can be reconsidered.
It's too bad VSCode doesn't "hydrate" features on an as-needed basis or on demand. Imagine it opens by default with just text editing and syntax highlighting, and you can opt in to all the bells and whistles as you have the need with a keystroke or click.
The questionable reliability of documentation is the big problem, for sure. It would be nice to be able to collect metadata such as referral dates and even comments. If you visit the docs, tick a box that says, "I referred to this and it was accurate," or, "This needs to be updated," etc.
What your critique does not address is the hardware aspect of the pi. GPIO pins engage many people who are interested in seeing tangible results of programming.
Fifteen years ago (I remember the apartment where I had this thought), it occurred to me that time was running out to write an authentic novel. Soon, computers would generate whole stories in an endless variety of styles, and even if future authors would hand write a book from start to finish, they would likely have been influenced by other artificial writing at some point. Readers would be unable to emotionally connect with authors due to the nagging awareness that the text might have been fully or partially generated by an unthinking, unfeeling machine.
Though I try, I fail to think of a comparable scenario in our past, at least as relates to language. You can look around whatever room you are in and try to identify an object that was made by human hands rather than a factory process. That's a fact that always makes me a bit sad. I think we're headed in a similar direction with the language we consume. Craftsmanship falls by the wayside, and our world loses even more of the human touch that connects us with one another.
If I had to guess, this is probably not even Adobe's fault. They probably have a legal requirement to do this, like every goddamn site asking you about cookies.
I'm trying to think of a reason not to just drop a microSD card in the mail addressed to the journo. Are we going to do better than physical media delivery? The only way to be found out would be some sort of surveillance of the mailbox or your fingerprints/DNA, which you could be careful with.
I work with a guy who makes a lot more than me, and he describes his salary as "spending money" because he has so many other ventures, contract jobs, and investments. His attitude about code is that no one in the future is going to look at your code like it's the Iliad. It's not art. It's just a tool. Almost none of us have any legacy to speak of with regard to this work. Your priorities as a father are worth it. You and your child will remember and cherish a day at the park far more than a well designed program.
Some people advocate for a secure httpOnly session cookie for the client, letting the server hold onto the JWT and manage refresh. This gets you the benefit of server to server access via the token as well as the "session" concept and the warm fuzzy feeling of knowing the client doesn't hold the token.
How do you find out a single token got leaked within the token lifetime? If it's that easy to detect a leaked token, why aren't you stopping the leak in the first place?
I'm unconvinced of the author's actual understanding of common JWT usage.
Suppose you use Azure. You may have one or more app registrations with defined roles as well as apis exposed within the Azure config. It's convenient to acquire an access token that can be sent to various apis, each of which can accept the token without having to worry about session state or really anything to do with authentication other than validating the token's legitimacy. If I wanted to roll my own security, maybe JWT isn't how I would choose to do it, but I definitely don't want to do that.
Some feedback on your site's UX - on desktop, I don't expect hovering on a menu item to open a new context, so by habit I click on it. You're opening on hover, though, and my click is closing the context immediately.
I would guess it's often better to make a slightly more complicated interface if that is what provides the best experience for an adept user. If you need the interface to satisfy the needs of a user from the first minute they experience it with no effort on their part to become more skilled, then you sacrifice a lot.
Software that is very enjoyable to use as you gain more intimacy with it is Ableton, which is used for music production. When you first see it, you're likely to think it looks dated and not too sophisticated. However, as you grow in your knowledge of how to access various features, you come to appreciate that it has been designed exceptionally well. For software that someone will spend significant time using, the goal should be a low barrier to entry and a high skill ceiling.
There is a certain personality type that likes to reimagine that their original thinking was not flawed, even when presented with a detail that they did not incorporate into their original thinking. If the detail had been in their awareness from the start, they would have arrived at a different position, but they are bound to a strict sense of linearity for reasons inexplicable to me except for ego protection.
Coming from dotnet, I rather like the Go pattern as you've described it. I would normally catch and error and then write out a custom message with relevant information, anyway, and I hate the ergonomics of the try{}catch(Exception ex){} syntax. And yes, it is tempting to let the try block encompass more code than it really should.
This may be a crazy/dumb take, but would it be so wrong to allow code outside the function to take the wheel and do a return? Then you could define common return scenarios and make succinct calls to them. Use `returnif(err)` for the most typical, boilerplate replacement, or more elaborate handlers as needed.
The saying makes less sense to a modern audience. We can all pull out our phones and likely show the same time due to network time sync. BUT, what if we have 1000 phones all showing the same time, and they are ALL wrong? New layer to the sentiment....