Don't blame the language, blame the library. At least it's not part of the standard library - in C, if you accidentally pass a user-provided string to the first argument of printf() you could be in just as much trouble.
642 karma · joined June 25, 2014
And what are we optimizing for anyway? Reading a bunch of code that uses an off-the-shelf library's Stack or Tree or whatever is always going to be easier to read than having to also have to inspect the three hand-rolled Tree implementations, two of which are probably buggy, in addition to the actual client code trying to use the tree to do real work. Or a library that implemented it using interface{} which is a big middle finger to the whole type system, completely discarding the compiler's ability to detect otherwise trivial mistakes.
For full details of how this works, use a vulnerable log4j version, log a simple (bad) lookup, and step through with a debugger for a while.
Sources:
- https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/com/sun/naming/internal/ResourceManager.java#L422
- https://github.com/JetBrains/jdk8u_jdk/blob/master/src/share/classes/javax/naming/spi/NamingManager.java#L558
- https://github.com/JetBrains/jdk8u_jdk/tree/master/src/share/classes/com/sun/jndi/url
So for example, if your schema, the class will be "com.sun.jndi.url.ldap.ldapURLContextFactory".
But also note that many of these schemes can return referrals/redirects to other protocols.
I spend 90% of my time on my "daily" notes, so (selfishly) that's where I would focus. My challenges there are:
1. My date format is "YYYY/MM - MMMM/YYYY-MM-DD" in a folder called Daily, which means the files have names like "Daily/11 - November/2021-11-18.md" (and surprisingly, Obsidian accepts that date format and manages the intermediate directories just fine). That crazy date/filename format would need to be configurable and supported for (I think) the Journal feature to work well 2. I don't include a heading with the date at the top of my Daily files (actually, _any_ files), so finding the right note (when I see a bunch of cards that all look pretty similar) can be challenging - at least my directory structure means I can narrow down to the month very fast by looking at the folder names 3. Bonus points for a calendar view to make #1 and #2 easier?
I think if I had to pick the biggest challenge, it's #2 because I end up with a big soup of files that all look the same, where the important thing to discriminate between them is the filename.
I also love the commercial model - I love Open Source, but I don't mind paying for quality, so I get the best of both worlds here. And more importantly, I don't have to spend a huge amount of money just to trial the software for a couple months - I can pay the (small) monthly fee, and if I like it, either pay the "full" fee or just keep paying monthly.
And if some day something happens to Obsidian, I'll just go back to Vimwiki. After all, my conversion process moving to Obsidian consisted of the single step of opening my existing Vimwiki directory structure with Obsidian...
The last time we reviewed the Atlassian Cloud hosted products, they did not meet our security needs (requirements include isolated tenant from other customers, customer managed keys, etc) though they were much closer than a few years earlier. We also review the general security practices of the company (for example to make sure they implement a secure SDLC and follow other security best-practices).
Funny. When I first switched from iPhone to Android, I downloaded a podcast player app one day. It has about 9000 knobs, levers and other controls to customize everything you could possibly imagine. Years later, I still have no idea what most of them do. But a few of them have been incredibly useful over the years. Advanced, complicated options that I had to Google or read Reddit threads to understand. Things that I could have survived without, are probably not used by very many people, but for those that do use those features, life is better with them.
Anyway, as soon as I had a cursory glance around the app, I immediately purchased the paid/pro version, not yet even knowing if I'd ever use the app again (at the time I didn't know when I'd even have time to listen to podcasts). These were my people.
I don't think it's possible to build a queue-as-a-service that is any simpler than SQS, so there is literally no better name than SQS. (also, the suggested name "Amazon Queue" is pretty similar to the name "Amazon MQ" which does in fact exist)
It's a queue. It supports enqueue and dequeue. And that's pretty much it. It's a Simple Queue Service.
That's funny. Because we have hundreds of developers using AWS every day, using IAM all the time, and never using a single IAM User.
IAM is actually named extremely well. identity and Access Management. I can't think of a better name. And if your problem is that you just don't like acronyms, you probably picked the wrong industry.
And if there is a differently-licenses _implementation_ of the protocol, one would assume that it is possible to implement (or just use directly) that implementation without any reliance on this specific specification document.
In other words: IANAL but I don't think this will accomplish what they want (which is Amazon re-implementing a wire-compatible-with-MongoDB database)
As an example: I (probably) can't scan and redistribute an entire cookbook, but I can bake cookies from a recipe in the cookbook and sell them.
Somehow, I have two different Apple accounts. Both are tied to the same e-mail address (which _should_ be impossible, and in fact, if I try to edit the profile of one, it complains that I can't do that since the e-mail address is already in use). This means that whenever I want to set up an iDevice, I need to log in to one account, download all the apps I want from there, then switch the App Store to the other account, and download the rest of the apps.
Of course, Apple support told me to pound sand. But at least they were friendly about it.
Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work.
More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.
Again: Code is always "low-level" (regardless of how much you do or don't know about the rest of the system) just like most API documentation. The complaint of the original article wasn't about API documentation, but about higher-level conceptual documentation being lacking. And just like not all "coders" may be able to design a large and complex system (though they may certainly be able to understand it) they also may be unable to document those high-level conceptual aspects of the system.
Modern programming languages and frameworks are explicitly designed so that you don't need to see how your code fits into the whole. That's the whole point of building abstractions, because it's too hard to keep all of the details in your head at one time. Writing code is generally concerned with the low-level details, which are hidden from other parts of the system (and that's a good thing). When you ask someone a coding question, that's what you are testing. To the point of the article, yeah maybe there is some correlation between someone who is good at writing code and good at writing API documentation.
The complaint in the article is that the high-level conceptual documentation is lacking. The systems design stuff. The architecture. And while there are certainly people who are good at writing low-level code as well as understanding high-level architecture, that's not always true, as they are very different skillets (and I don't mean this as a slight against anyone, it's probable that most people who are good at one could become good at the other, but in practice, many people's jobs lead them to spend more time on one instead of the other, so that's where they build up skills and experience).
Anyway, the higher-level documentation is a very different style of writing. It needs to read like a book (as opposed to API documentation which is more like a dictionary or encyclopedia). You need to be able to pull information together from lots of places, and it must be presented in a methodical way, where (for example) you can't assume that the reader has knowledge of something before you have presented it.
I'd bet, for every HN commenter extolling the virtues of some new language, framework or database, there are 10X that many developers quietly hacking away writing boring and ugly VB (and Perl, Java and whatever other languages people consider uncool) code on an ancient MySQL or SQL Server or MS Access database, solving real problems, and getting the job done. Which, in the end, is all that really matters.
(I consider myself a professional, I try to pick the right tools for the job, design maintainable systems, and write clean code, but at the end of the day, I'm paid to deliver value for the business, not build a monument of coding perfection. Life is full of tradeoffs)
You can choose not to support Zionism. But if you actively believe "Jews should not have a homeland" that is anti-semetic.
Let's be clear though: Anti-zionism is a form of antisemitism. People can rationalize all they want about how/why it isn't, but they would be wrong. You can argue all you want about the policies of the current Israeli government, but anti-zionism is still a form of racism.