HackerTrans
トップ新着トレンドコメント過去質問紹介求人

asQuirreL

293 カルマ登録 12 年前
Email: $ echo -n "YW1lbm9uOTQgW3NBbFRdIGdtYWlsIFtET1RdIGNvbQ==" | base64 -D

Stack Overflow: http://stackoverflow.com/users/1091208/amnn

Github: https://github.com/amnn

コメント

asQuirreL
·8 日前·議論
> on the surface looks like an ORM but is in fact a set of clever functions that write SQL

Honest question -- what's the difference?

Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance.

I'm not saying that the ecosystems you mentioned aren't doing something different, I just don't know what it is from how you've described their DB layers.
asQuirreL
·3 か月前·議論
A carry lookahead adder makes your circuit depth logarithmic in the width of the inputs vs linear for a ripple carry adder, but that is still asymptotically worse than XORs constant depth.

(But this does not discount the fact that basically all CPUs treat them both as one cycle)
asQuirreL
·4 か月前·議論
Post can be summarised quite succinctly:

Everything was slow because sorting was taking a lot of time. Sorting was slow because its comparator was taking ~6 read locks on every comparison, and was cloning large structures to avoid holding the lock for a long time. The first fix was to access just the information needed to avoid the clones, the second fix was to cache exactly the data needed for sorting after the underlying data was updated, and use that for the comparators without needing to take the underlying lock.

I'm looking forward to the next post about how cache consistency is tough.
asQuirreL
·5 か月前·議論
It can be (cross-)compiled on whatever architectures the Zig compiler is available for, but the source contains inline x86 assembly, so you're not going to be able to build this for ARM or RISC-V.
asQuirreL
·6 か月前·議論
This sounds like advice for how to be promoted to a specific level -- the first point where awareness of things beyond yourself is required (somewhere around the Senior or Staff level for ICs, depending on your company).

Generally everyone in a team should be working towards some shared goal, there's no level at which you can be a chaos agent and not serve some higher purpose. The difference at this level transition is that you realise that for yourself -- someone doesn't need to remind you of the goal and nudge you back on course. That same realisation is not going to cut it at higher levels.

For me the general version of this advice is not something you can just tell the person who's being promoted, it's collective advice, for them, their manager, their tech lead: everyone needs to agree that this person needs to be given more rope, they need to do something useful with that (i.e. not hang themselves with it), the people around them need to watch out for when they start tying a noose and help them untie it (already regretting this analogy), and that's how you get promoted.

The rope takes different forms for different levels. I'll use the level scale I'm familiar with, starting with a newly graduated engineer at L3:

- L3 -> L4. You help decide how to build the feature.

- L4 -> L5. You help decide what features are worth building, and are trusted to maintain them.

- L5 -> L6. You help shape the work and ongoing maintenance of ~10 people's work (what products are worth building and how), over a time horizon of 6 months to a year.

- L6 -> L7. ~50 people's work, 1-2 years.

- L7 -> L8. ~200 people's work, 2-5 years.

- L8 -> L9. Things start to get fuzzy. The pattern suggests that you have a hand in ~1000 people's work, which is possible to do in the moment, but rare. There's two ways I can think of: you're either a world expert in your field, or you have set the technical strategy well for your organisation as it grew to this size.

This is just based on my experience, working largely on infrastructure teams both in big tech and in start ups as both an IC and a manager (currently an IC).
asQuirreL
·9 か月前·議論
I think what's more important than the character count is the fact that you can add #p with two key strokes.

Inserting parentheses requires moving your cursor around or invoking some shortcut in your editor if you use paredit, vim-surround, or a similar plugin. Applies equally for removing the invocation (although paredit makes that part easy).