What withinboredom meant is that running processes in containers don't add overhead vs simply running them outside of them. That is mostly true because of the way that containers work in linux through cgroups and namespaces, which means that you would only be limited by what your hardware would already be able to run before running the processes in containers.
Since finding out about Kowloon walled city, I have been fascinated with it. Most cities have sections (usually older parts of them) that are maze like, and they are often my favorite parts of those cities.
It reminds me of the hive cities of Warhammer 40k.
Another analysis of Kowloon I enjoyed is this one by the architect Dami Lee [1].
I prefer using markdown files in a repo and generating my website using a SSG, because I find managing plain text files and a simple CI/CD pipeline to deploy easier to manage. The tooling for writing is my editor of choice, deploy is a git push and I don’t have to run a server or long running process. I can also easily migrate to any type of hosting more easily.
I can see someone who is more used to Wordpress for example finding your workflow easier. It really mostly comes down to personal preference and what tools you are used to.
My understanding is that this is usually done by companies that need to implement delegated authorization which is the bread and butter of OAuth 2.0. By starting and implementing their authentication flows with OAuth2, you can support both delegated authorization and native authentication where your own apps are simply OAuth clients with some special casing. That isn’t absolutely necessary since you could build authentication separately from OAuth but then you would still need those OAuth2 flows for delegated authz eventually if you do.
I have found 1 to 2 week leaves not unusual. I am taking a month off this year after not taking any ptos around the holidays other than the mandatory ones for the last several years. I think I have seen summers to be much more common for long time offs.
To add another data point, I also moved on from Postman a while ago. Similarly to several commentors here I had found it to have become bloated, slow and buggy imho. In my particular use case, I found the urlencoding when using oauth1 to be pretty buggy. It would sometimes not work on certain headers it generated.
My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia which doesn't seem to be much better in my opinion.
I recently found httpyac[1]. It's a cli and file based http client similar to the IntelliJ HTTP client, but has plugins, hooks and allows scripting through javascript blocks. It seems to have everything I need but I haven't used it much yet. It also already supports gRPC.
One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request. Postman did provide some of that but that's one area I wanted more from any client I looked at. I could of course simply wrap curl in a script but at that point, I will be maintaining my own jerryrigged version of an http client for my team.
The IntelliJ http client is absolutely brilliant. I love that using it is just editing a text file. Even if I didn't use everything else in IDEA, it would be worth it to fire up the IDE just for http scratch spaces.
Yeah I stumbled on this just the other day as well when reading about another IDE from JetBrains (I've been a paying IDEA customer for years). I'm looking forward to checking this out the next time I need to test HTTP endpoints. Postman has been decent for my needs but I always found some basic stuff to me way more difficult than it should be. The scripting in IDEA is something I'm very interested in. Postman had some of that but was more difficult that it should have been IMHO. Also I really like the idea of all my requests being text-based and something I can just commit alongside my code.
Devs at our company predominantly use IntelliJ's builtin HTTP client. I think I've only seen QA engineers use Postman because they don't have developer IDEs installed.
Vscode has an http_client module that's very similar to intellij's as well. Practically the only thing you've gotta change is how requests are saved to variables
I moved on to a system of Bash scripts checked into a company repo. Sounds silly, but it works. It's version controlled easily, you can refer to the scripts from documentation, and it's cross-platform.
Never heard of httpyac. Looks pretty nice. We've been using httpie, which works great, but it's missing nice-to-have stuff like graphql and oauth2, which I've had to build in myself.
> My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia
One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS. No one will ever agree on one Linux distro. No one wants to develop on Windows (unless you’re developing for Windows). So you should but everyone a MacBook. The time saved by reducing duplicated work in getting things working on your OS more than pays for the Apple tax. As for personal OS preference - get over it.
> One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS.
Why stop there? You may also deny engineers admin access so they can't install unauthorized software alternatives to the one true path(tm). The policy is really solidified by not revising the list of blessed software for many years[1], assuring there are no support tickets, and your stack is truly 'stable'. Why let software engineers choose which software they'd like to install?
1. Eclipse is on the list, always has. Jetbrains requires skip-level approval as support is still experimental. What is VSCode? No one knows the process of adding it to the approved packages.
> some team members are also using insomnia which doesn't seem to be much better in my opinion.
In my experience Insomnia suffers from some of the same bugs that affect Postman[1], but at least they don't do the scummy things that Postman does, for example locking you out of your _personal_ Postman account if your ex employer forgets to pay their business subscription (if anyone at Postman is reading this: that's the reason I left and will never come back).
PS I swear that some time ago I saw that Paw was now available for Linux and Windows as well, but I just went to their website and it still says "exclusively built on macOS", I'm really confused now.
My main complaint is that it’s terrible at restoring local state. With sublime text I can just leave whatever I had opened and shut my computer down and it’ll be back to where I left it. With Postman the tabs will kind of be there but when you open one it just says it couldn’t do something or another and all the input data is gone.
I often have unsaved state because I’m testing a specific case that I don’t want to save
> One of the issues I found with http clients I looked into is that they often don't provide enough functionality to hook into the request process. Either before or after a request is executed to add to the headers or parameters of the request or getting the results of the request.
I find that httpkit (or just mitmproxy) often gives me decent insight to the actual requests.
I don't know about altering requests "in flight" - I typically re-issue the request via curl or my application server (eg: rails console or debugger breakpoint).
Strongly considering purchasing httpkit - but so far I've just needed it occasionally.
I feel like postman etc is closer to println Debugging, while just intercepting the traffic is more like using a real debugger. But I guess I can see why some like postman etc for exploration - so far i prefer swagger for that (or soapui for xml/soap - preferably running soapui under httpkit for the best of both worlds).
Thanks for sharing. Is the code for httpyac anywhere? I can only find the repo for the docs. I'm trying to check it out, but I encountered some errors when trying it add it as a global with yarn because I'm running a node version greater v14. The extension also gave me a deprecation warning about Buffer() usage.
It's built on a plugin architecture, does gRPC, GraphQL, JDBC, Ws, et.al. Other plugins allow sharing of workspaces to various services. Written in Java/JavaFX, brew or chocolatey install.
The use case would be the same as the one covered by jdbc and odbc. That is creating a standard interface to connect to databases at a lower level than the orm. This could then be used by an orm or query builder to communicate with the database. That’s how for example I can use Spring JPA and if I write either fairly portable sql or use the crud repository methods, I can connect to multiple different sql databases by simply providing a different jdbc URL.
How to handle the differing syntax of each databases would be handled at a higher level, by the query builder or orm. The orm could decide to let the user decide for themselves whether to write portable sql or not and fail at runtime, or like diesel in rust, enforce the useable features through its types.
In my experience that is something that is currently missing in the rust ecosystem. Each library seem to have its own connection logic and if I want to write a program that could run on different databases in rust right now, I have to write different code to connect to each database I would like to support.
Diesel has been serving me really well but I currently need to choose a specific backend when I am building a query, and implementing the above dynamic style of connection would be quite cumbersome to implement. It would be nice if we could choose another a standard sql backend where I would only be able to use a subset of features supported by most sql databases and build queries against that. Hopefully the RDBC project could help with something like that.
I think he makes some valid points. At first I was a bit ticked off that he is redefining what operating system means somewhat. But he is right in many ways and what really counts is the user experience(End user and developer). What mainly defines the user experience is the environment and GNOME is one. He touches on more than that and he does not leave out what is lower on the software stack. His confidence in the vision they have reassures me a bit that the linux desktop is still on the right way.
Well, I'm not convinced that it's mainly the environment. You noted yourself that he also talks about lower stuff like suspend not working. And suspend/hibernate not working is not the fault of Gnome. It's because of Linux itself. If he on the one hand redefines the Operating System as being the whole experience, he should not forget that the technical base defines the user experience even more than the GUI (The GUI s only important if the base is working). I doubt that with his vision of what an OS is, with his what i see as negleting the technical base, this would be better. I don't think that Gnome itself "has the talent to do almost anything". They won't improve the kernel that much when a base-function don't work, or fix graphic-drivers when their compositor won't work cause of a glitch in them. The DE is a part of the use of an OS, an important part of the daily work, but not the whole OS.
PS: Using Linux for years, I never had a system with working suspend/hibernate. And I still have not, using the newest Ubuntu on my laptop. Which really is disturbing when reading about a GUI almost forcing you to use that broken function.
At this point, it's the "lower" level issues - suspend, graphics, sound - that are ruining the Linux desktop, even for us geeks.
They were the reason I gave up on Linux desktop two years ago and forked over the extra money for a Mac. Closing your laptop and knowing it will work when you open it later!
BTW, we got new Dell laptops at work last year and found they would degrade with every suspend/resume (e.g. audio glitches). Did I mention this was Windows 7?
