Right, that's my point. Why would I want to use it? What is it actually for?

I mean, I guess if you're using their ORM then maybe it has some benefits, but I'm not sure I want to use an ORM at all. They claim that the query engine is useful on it's own but I don't think I want to use it.

The internet tells me it's great so I'm trying to figure out why

Regarding comments... back when I used emacs exclusively, I used to write lisp code in the comments and execute it with emacs inline, to do stuff like generate hairy constants or SQL queries and stuff. It's kind of hard to visualize maybe but the idea was that I could write a little bit of code in a comment that was basically like... "run this code and replace the next line with the output of it"

Other people hated it, so I quit doing it.

So is it pretty standard for a pre-Series A startup to offer 1-2%, particularly if they'll probably be staffed <20 until then? Would that get diluted down at all as Series A or Series B gets awarded?

He said I'd own 2% when the company sold. Haven't gotten the official offer yet, just discussed terms.

Yeah I'm just wondering if that's a standard ballpark offer for a company of that size at that stage.

Learning me some Docker and setup.py today.

Docker reminds me of GNU Screen, but a lot more powerful. Pretty simple to use.

At least from what I've heard/seen, more than 1% is well above standard when combined with a near-market salary. Somewhere between 0.20% and 1.0% is more standard.

I'd definitely nail down vesting terms and other conditions (termination, etc).

I'm briskly walking through these react/flux/redux tutorials for a JS evaluation at the day job and possibly to help out at the startup.

Seems like you better already be a JS expert to pick up react - with inheritance all over the place, stuff like this.someFunction.bind(this) all over the place, immutability with redux state, a bunch of other pretty high-level JS concepts. Angular has a learning curve too - but I don't remember it needing this level of deep JS understanding.

Our offshore devs would get into such a mess with bind(this) and immutability. I would send out emails and git comments to the tune of "Did you remember to .bind(this)?" all day long.

Also because I am old and it's late and my brain is slow. This:

Is the same thing as this:

Right?

He calls the code in the first example a "series of thunks" which makes me make sad bear face. Also notice 2-space tabs like all sane people.

I do have to say redux middleware is pretty cool.

I don't know SQL Alchemy in particular, just talking persistence frameworks in general (mostly hibernate).

The added security is quite huge by itself. If you are writing raw SQL queries you need to manually make sure all the parameters are correctly sanitized/escaped and it only takes a relatively minor mistake to open yourself up to SQL injections. If you use the query builders then the framework is responsible for escaping the parameters correctly and SQL injections should not be possible unless there is a bug in the framework.

Caching and easy control over eager/lazy loading of references is another huge plus, but that part usually requires the use of ORM.

What monitor is that? I've always only seen 30" monitors at that resolution.

Not a fan of that terminology either - there's a better name for this

https://en.wikipedia.org/wiki/Currying

Yeah Angular has a steep learning curve but it's not really about JS but its own conventions and terminology that were more influenced by a backend/server-side/Java culture. React (and most of its ecosystem) is much more of a pure JS framework by JS developers.

I learned JS and went straight to react/redux, no problem

lol I don't think you're the type of developer that suzzer is concerned about here.

I put es6's implicit "if your fat arrow's next character isn't a {, its return" on the same level of use as those *******s who do 2 line if statements without curly braces i.e. don't use it.

Every major python database library supports parameter escaping - if you're using string formatting to insert fields then you're making a mistake but as long as you know not to do that, they should be fine.

The eager/lazy loading looks very inefficient to me, given the SQL it generates. It doesn't really make sense to me in the context of web apps either, because the object lifecycle is short and easy.

Probably not, but I'm also not a "javascript expert"

It might be 30". I don't rembember the model off hand. When I went to look the other day they were no longer selling them. At the time I bought it, it was the big apple killer.

Yeah I've been reading similar. 2.5 years ago I passed on an opportunity to be employee #18 at a pre-series A startup. Earlier this year they got their series B and I just recently found out it was at a $220MM valuation. I never went as far as to see an offer, but even if equity share were only 0.25% that's worth half a milly right now, and they're still growing strong. I've been fairly depressed ever since.

From what little of React Ive looked at, it looks like itll get annoying keeping track of what component each prop is coming from. Could just be a function of the tutorial I was watching. Also that bind thing scares the crap out of me as well

huh? components/props are 1 way child/parent relationships so you always know where they're coming from. The bind thing is just trial and error too i.e. after you work with it for a bit you'll realize when you need to bind this.

I think it was more the example of changeTitle in this that was confusing/seemed wonky

-1000.

fat arrow implicit return is like the whole point of fat arrows, it's what allows you to write more readable code with them. in general anything that removes boilerplate is a good thing -- and braces and the word "return" are boilerplate.

is infinitely better than

i mean, i don't even think i can concede this is a matter of taste. preferring the 2nd is just factually wrong

well, there isn't much inheritance anywhere -- or there shouldn't be. the thing about the other concepts you mentioned is that, yes, they will certainly be difficult for those with little experience in functional programming, and i wouldn't just throw them at offshore devs.

but the key point is that they aren't react specific concepts... they're standard principles of functional programming that can be applied anywhere and in any language supporting first class functions. so you're really learning to fish, rather than accumulating a bunch of framework knowledge with a 2 year expiration date. (not saying that there is none of that in react). i judge frameworks (or preferably libraries) by how much they lean on general principles and built in language features, and how little they force of themselves on you.

I don't mind simple implicit returns like your example but complicated ones like suzzer's currying mess are total garbage IMO. fancy play javascript syndrome.

I find the first example a lot easier on the brain than the 2nd. I just got thrown by "series of chained thunks" or whatever.

The guy who makes those videos (which seem like the most popular/comprehensive react tutorial out there) seems to favor inheritance over say closures to solve problems.

I get what you're saying and at anything other than hyper-mega-corp with a team of offshore devs I agree. Unfortunately at my day job you have to consider stuff like - it's a lot easier for most offshore devs to learn a flat structure with a lot of stuff vs. deep JS understanding.

I get the feeling their schooling emphasizes rote learning over understanding. IE - when I went over to India to teach my node class, most of them got tripped up on these two quiz questions:





And these were the best of the best, many of whom went on to become good developers. With exceptions (like the amazing architect) they just don't seem to be trained to think about the higher level concepts of what they're doing, as opposed to memorizing a list of things and how to use them.