Technically maybe someone could make you navigate to that url in the future, through mitm or some sort of DNS poisoning, and autofill a form with your password and then auto submit it.
"Unrelated" doesn't sound right. Zendesk refused to pay for the vulnerability, so the researcher used it against downstream customers of Zendesk, who did pay the researcher for the impact of that Zendesk vulnerability against their own company.
> Side note: I'm not too surprised, as I had one of the worst experiences ever interviewing with Zendesk a few years back. I have never come away from an interview hating a company, except for Zendesk.
Same thing happened to me years ago. Interviewed with them and it was the worst “screening” experience I ever had. After getting a rejection email, I thanked them for their time and said I had feedback about the interview should they want to hear it. They said yes, please.
As a big advocate of Asciidoc myself, I have to say this sounds backwards to me too.
I can't imagine someone calling themselves a developer finding writing asciidoc difficult. It isn't any harder than markdown. It only has a slightly different syntax[0], and more features.
I've also faced a lot of resistance from people when asking them to migrate from markdown. My, unfavorable, opinion is that it's simply the usual reluctance to change and unwillingness to learn something new, deal with the short term pain of learning, despite longer term advantages.
* The ordered list isn't the best way to write numbered lists. Numbered lists can be: 1. 1. 1., etc. The computer will auto-increment.
* Typographic quotes are an extension. I wrote KeenQuotes[0] to solve the quote curling problem and integrated it into KeenWrite[1].
* Document header. I fundamentally disagree with putting formatting instructions into plain text documents, in either AsciiDoc or Markdown. I wrote KeenWrite to completely separate the two. Documents are typeset using ConTeXt[2] and a theme[3].
* Admonitions. Pandoc (and KeenWrite) supports annotations in Markdown. I used them on page 5 of my Impacts Project[4] to insert the spectra. I'd say that annotations are more flexible than admonitions because admonitions are often canned (TIP, WARNING, etc.); whereas, annotations are user-defined.
* Sidebars and block titles imply presentation. These are also handled by annotations.
* Includes. You can use R Markdown to get includes. Or write an extension. Fair point that it isn't bundled, though.
* Custom CSS. Again, avoid mixing presentation and content. Specific presentation logic can be applied by annotating the content, rather than trying to format plain text as though it was HTML.
* Definition lists. Supported by Markdown, I use them for a glossary in a novel I'm writing.
* Tables. While perhaps not CommonMark, basic tables are widely supported by almost all Markdown implementations.
There's a fair amount of incorrect, biased, or outdated information on that page.
Here's an example page written in Markdown and made into a PDF:
With that architecture, the source document format doesn't matter. Take any input document, transform it into a structured document format (such as XML), and then typeset it. Pandoc has a similar architecture.
> This isn't a matter of technical chops, this is a matter of someone who is good at navigating bureaucracy convincing the powers that be that they should have a special hook into the system.
I would love to know how one can get what I'd imagine is at least a 6 figures contract with the government? How does this work?
I imagine the author of FlyCASS must be making a good amount of money off their product.
> he answers questions from newbies and enhancement requests are far more polite and charitable. His ire seems to be reserved for fellow programmers.
Some programmers (like myself) have little patience for people they consider should know better and are wasting their time. These same programmers are far more charitable to newbies because they know newbies are still learning.
> Remember that this is the guy who said he would personally maintain python 2 because he didn't want to rewrite calibre for python 3 [0].
I read his "I am perfectly capable of maintaining python 2 myself." as "I am perfectly capable of maintaining [calibre running on] python2 myself", which is completely different.
I'm sure some people might also find his answer quite terse and dismissive ("No, it doesn't."), but I read it as a simple statement of facts, using the same tone as the original bug report, which itself is quite terse and imperative "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
> Some programmers (like myself) have little patience for people they consider should know better and are wasting their time. These same programmers are far more charitable to newbies because they know newbies are still learning.
Some programmers are life-long learners and know a very different subset of things. It’s important to remember that just because something is obvious to you doesn’t make it right and doesn’t make it obvious to others.
Totally agree. Though, usually these programmers know how to properly ask a question, make a bug report and/or feature request.
They wouldn't, for example, just barge in an oss project with arguably low value statements like "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
I am guessing you haven't interacted with the developer of kitty. It is astounding how needlessly rude he is. No matter our expertise, we all have areas of ignorance and it is precisely due to that ignorance that we may not have the language to "properly" frame our question. If we had that knowledge, we wouldn't be asking the question in the first place.
I have never seen a maintainer go so far above and beyond to condescend and insult people asking questions -- not making demands like your example. In my case, I asked a question about something that wasn't working as I expected in the github discussions and he repeatedly insulted my intellect (while simultaneously blaming another program when it was in fact a kitty misconfiguration that was causing my issue). He did eventually leave enough breadcrumbs that I was able to solve my problem but rarely have I had such a negative experience with asking an (IMO) not stupid question.
> I read his "I am perfectly capable of maintaining python 2 myself." as "I am perfectly capable of maintaining [calibre running on] python2 myself", which is completely different.
That doesn't make sense to me in context. Presumably he was already maintaining calibre on python2 at the time, so what additional information is he adding?
It seems more like he was saying "I am perfectly capable of maintaining my own fork of python2 for however-much-python-I-need to continue developing calibre." Which, granted, is not as grandiose as "I will become the maintainer for the abandoned python2 language for the internet at large to use", but it is still a rather tall order.
I worked many years with an open source eCommerce platform called Magento[0] which, at the time, used something called the "Entity Attribute Value" (or EAV) system[1].
One particularity of the EAV system is that you end up having tables with hundreds (and growing) of columns. It made Magento itself extremely hard to work with and optimize. I hope they moved away from this model since.
To be fair, this was before nosql databases were a thing.
Props to the author for writing this – that being said, I felt the same way.
Very long, windy and hard to parse sentences.
For example, Part 2
> There are two basic techniques that you can employ when analyzing malware. The first being static analysis and the other being dynamic analysis.
> Static analysis uses software tools to examine the executable without running the actual decompiled instructions in Assembly. We will not focus on this type of analysis here as we are going to focus on actual disassembled binaries instead however in future courses we will.
> Dynamic analysis uses disassemblers and debuggers to analyze malware binaries while actually running them. The most popular tool in the market today is called IDA which is a multi-platform, multi-processor disassembler and debugger. There are other disassembler/debugger tools as well on the market today such as Hopper Disassembler, OllyDbg and many more.
> A disassembler will convert an executable binary written in Assembly, C, C++, etc into Assembly Language instructions that you can debug and manipulate.
> Reverse engineering is much more than just malware analysis. At the end of our series, our capstone tutorial will utilize IDA as we will create a real-world scenario where you will be tasked by the CEO of ABC Biochemicals to secretly try to ethically hack his companies software that controls a bullet-proof door in a very sensitive Bio-Chemical lab in order to test how well the software works against real threats. The project will be very basic however it will ultimately showcase the power of Assembly Language and how one can use it to reverse engineer and ultimately provide solutions on how to better design the code to make it safer.
> In our next lesson we will discuss various types of malware.
could be written:
> There are two basic techniques that you can employ when analyzing malware: static analysis and dynamic analysis.
> Static analysis examines the executable without running it. We will not focus on this type of analysis here, however in future courses we will.
> Dynamic analysis uses disassemblers and debuggers to analyze malware binaries while running them.
> A disassembler converts an executable binary into Assembly Language instructions that you can debug and manipulate. There are many disassembler/debugger tools available such as Hopper, OllyDbg, IDA and many more. The most popular being IDA, a multi-platform, multi-processor disassembler and debugger.
> Reverse engineering is much more than just malware analysis.
> At the end of our series, we will use IDA in a fictional scenario where you will be tasked by the CEO of ABC Biochemicals – a very sensitive Bio-Chemical lab – to ethically hack his company’s bullet-proof door control-system.
> The project, while basic, will showcase the power of Assembly Language and how one can use it to reverse engineer black-box binaries and ultimately find solutions to make the code safer.
> In our next lesson we will discuss various types of malware.
Well, that’s kind of the problem isn’t it?
Yes, you can put bogus URLs, but it’s far from a great user experience
reply