As easy as 1, 2, 3!
Updated:
- Aug, 08, 2022 update
config
docs for npm 8+ - Jul 27, 2021 add private scopes
- Jul 22, 2021 add dist tags
- Jun 20, 2021 update for
--access=public
- Sep 07, 2020 update docs for
npm version
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
Since this is on Hacker News and reddit...
_t
in my types. I spend a lot of time at a level where I can do that; "reserved for system libraries? I am the system libraries".char *
s.type * name
, however, is entirely intentional.This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array
it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array
part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
--- | |
language: objective-c | |
before_script: | |
- ./scripts/travis/add-key.sh | |
after_script: | |
- ./scripts/travis/remove-key.sh | |
after_success: | |
- ./scripts/travis/testflight.sh | |
env: | |
global: |
I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!
\
These ideas are WORK IN PROGRESS!
The core idea with this workflow is that we end up with a self contained docker image of your application. This image will not only contain our code, but also all the dependencies that are neccessary to run the code. This image can then be used for both, easy deployment in production and as basis for ongoing development.
The image is not a static, though. In fact, it will see many revisions over time - which is supported nicely through dockers inheritance approach. We basically
Picking the right architecture = Picking the right battles + Managing trade-offs
If you, like me, resent every dollar spent on commercial PDF tools,
you might want to know how to change the text content of a PDF without
having to pay for Adobe Acrobat or another PDF tool. I didn't see an
obvious open-source tool that lets you dig into PDF internals, but I
did discover a few useful facts about how PDFs are structured that
I think may prove useful to others (or myself) in the future. They
are recorded here. They are surely not universally applicable --
the PDF standard is truly Byzantine -- but they worked for my case.