DSG (Destitute Streetdwelling Guttersnipe) Destitute-Streetdwelling-Guttersnipe
Okay, the title of this post is a bit of a lie. There's no one secret trick to becoming a genius programmer - there are two, and they're more habits than tricks. Nevertheless, these kind of 'secret tricks' seem to resonate with people, so I went for this title anyway.
Every once in a while, a somewhat strange thing happens to me. I'll be helping somebody out on IRC - usually a beginner - answering a number of their questions in rapid succession, about a variety of topics. Then after a while, they call me a "genius" for being able to answer everything they're asking; either directly, or while talking about me to somebody else.
Now, I don't really agree with this "genius" characterization, and it can make me feel a bit awkward, but it shows that a lot of developers have a somewhat idealistic and nebulous notion of the "genius programmer" - the programmer that knows everything, who can do everything, who's never stumped by a problem, and of which ther
(This Gist is a work-in-progress, and things may be added or changed over time.)
If you're not familiar with the concept of an 'event loop' yet, watch this video first. While this video is about the event loop in JavaScript, most of the concepts apply to event loops in general, and watching it will help you understand Tokio and Futures better as well.
- Futures: Think of a
Futurelike an asynchronousResult; it represents some sort of result (a value or an error) that will eventually exist, but doesn't yet. It has many of the same combinators as aResultdoes, the difference being that they are executed at a later point in time, not immediately. Aside from representing a future result, aFuturealso contains the logic that is necessary to obtain it. AFuturewill 'complete' (either successfully or with an error) precisely once. - Streams: Think of a [
Stream](https
A "prefix code" is a type of encoding mechanism ("code"). For something to be a prefix code, the entire set of possible encoded values ("codewords") must not contain any values that start with any other value in the set.
For example: [3, 11, 22] is a prefix code, because none of the values start with ("have a prefix of") any of the other values. However, [1, 12, 33] is not a prefix code, because one of the values (12) starts with another of the values (1).
Prefix codes are useful because, if you have a complete and accurate sequence of values, you can pick out each value without needing to know where one value starts and ends.
For example, let's say we have the following codewords: [1, 2, 33, 34, 50, 61]. And let's say that the sequence of numbers we've received looks like this:
1611333425012
- Package search (for stable channel)
- An unofficial multi-channel package search (for all recent channels, including stable - currently not being updated)
- Options search (for stable channel)
- A list of channels, and when they were last updated
- A timeline of channel builds
- A source code search (that actually works!) of all NixOS repositories; Nix, nixpkgs, etc.
Lower precedence means a stronger binding; ie. this list is sorted from strongest to weakest binding, and in the case of equal precedence between two operators, the associativity decides the binding.
| Prec | Abbreviation | Example | Assoc | Description |
|---|---|---|---|---|
| 1 | SELECT | e . attrpath [or def] |
none | Select attribute denoted by the attribute path attrpath from set e. (An attribute path is a dot-separated list of attribute names.) If the attribute doesn’t exist, return default if provided, otherwise abort evaluation. |
| 2 | APP | e1 e2 |
left | Call function e1 with argument e2. |
| 3 | NEG | -e |
none | Numeric negation. |
| 4 | HAS_ATTR | e ? attrpath |
none | Test whether set e contains the attribute denoted by attrpath; return true or false. |
| 5 | CONCAT | e1 ++ e2 |
right | List concatenation. |
| 6 | MUL | e1 * e2 |
le |
Yesterday, an article was released that describes how one person could obtain access to enough packages on npm to affect 52% of the package installations in the Node.js ecosystem. Unfortunately, this has brought about some comments from readers that completely miss the mark, and that draw away attention from the real issue behind all this.
To be very clear: This (security) issue was caused by 1) poor password management on the side of developers, 2) handing out unnecessary publish access to packages, and most of all 3) poor security on the side of the npm registry.
With that being said, let's address some of the common claims. This is going to be slightly ranty, because to be honest I'm rather disappointed that otherwise competent infosec people distract from the underlying causes like this. All that's going to do is prevent this from getting fixed in other l
| function Get-InjectedThread | |
| { | |
| <# | |
| .SYNOPSIS | |
| Looks for threads that were created as a result of code injection. | |
| .DESCRIPTION | |
Every once in a while, somebody comes into an IRC channel with a code question, and their code turns out to be a mess - very hard to understand, even harder to fix, and sometimes flat-out unfixable. This is usually followed by a recommendation towards the person asking the question, suggesting that they clean up the code first, and giving them concrete suggestions on how to do so.
Most of the time, this works fine - the asker cleans up the code and returns with a more readable version. Unfortunately, sometimes it does not.
Asking people on IRC a question means asking volunteers to give up their time and energy to solve your problem. This is fine, since that's what people are there to do in the first place - however, it means that you are expected to put in your part of the effort as well.
When you respond with something along the lines of:
NOTE: This is simplified. However, it's a useful high-level model for determining what kind of database you need for your project.
- Documents: Single type of thing, no relations
- Relational: Multiple types of things, relations between different types of things
- Graph: Single or multiple types of things, relations between different things of the same type