Anyone have any thoughts on using async.series vs. chaining promises? (async js, not async/await)

The former just seems so much cleaner to me and gives some guard rails for new devs and help with error handling. But then again I haven't worked enough with promises to be completely comfortable with them yet like I am with async or middleware.

lol Haskell. Talk about a language that everyone talks about being awesome but nobody really uses it to build serious stuff.

I have a few projects I've done so far that I'm gonna clean up this weekend, get a personal website up, and then start applying next week.

I don't think you're going far enough - concerns about boilerplate are also massively overblown. Type inference beyond simple local inference is kind of overrated for most languages as interfaces should be clearly documented anyhow. Trying to build complex things in dynamic languages ultimately leads to things like writing out types in comments, React.propTypes, linters that do type checking, etc, all of which are worse than standard boilerplate in statically typed languages and compilers doing their thing.

i'd actually use async/await instead of either if possible.

between the other two options i guess async.series...

yeah, people do all sorts of crap that they don't even realize are just poorly implemented type systems.

what i was really getting at is that if your building anything of even moderate complexity, the largest task is just thinking through what all the types are in your domain. even if your using ruby and javascript, you still need to do that step, it's just what you end up with often isn't enforced, or it's enforced only partially at runtime, etc.

Ok google seemed to suggest chaining calls in async/await was more complicated than with promises. But is it really just this simple? Is it the error handing part that gets messy?

Hmm maybe it was parallel that is harder.

https://medium.com/@bluepnume/learn-...t-eb148164a9c8

https://wiki.haskell.org/Haskell_in_industry

I'd say a lot of that is more serious than the average food photography site.

Coolio. You are mostly JS and RoR at that school, is that correct?

We're onto node now.

Next project is Node + MongoDB.

I'm super pumped to be learning node, Mongo I'm interested in, but from what I have read/been told, etc. it seems overhyped and with very narrow use cases that people tried to force for stuff that wasn't ideal.

Well it's ideal for bootcamps/hackathons - that's for sure.

I wouldn't say it Mongo has narrow use cases - it works okay for a wide variety of use cases but is rarely the best for any given use case. It's easy to get started with, that's for sure, which contributes to its viral success. I think it's a good blueprint for success if you're in the business of creating tools and components for developers, whether framework/database/library/etc - be easy to start with and work well enough for lots of things. You could say the same thing for Rails and Django for instance.

We were talking about static vs dynamic typing but this is one area where dynamic typing wins - it's both easier to get started with as a user and easier to implement, combining two biases 1) developers make decisions based on whether something takes 10 minutes or 3 hours to get started, when that has no bearing on long-term cost and 2) simple implementations often win by being able to pivot and adapt quicker than "good" implementations (worse is better).

Stripe doesn't seem to let you charge more than:
Rp999,999.99 IDR

(Equivalent ~$75 USD lol). They seem to have a max limit of 8 digits regardless of currency. Makes taking IDR payments impossible!

I've used Mongo for years now and I really do love it. But its definitely hard to put my fingers on why, because there are a number of kind of janky things about it.

I always thought good variable names could be enough to compensate for not having type checking but people suck at naming things.

Like in haskell I always see single letter names for variables and you have to look at the type to see what it is. You see the redundancy in java with stuff like Logger<String> stringLogger = new Logger<String>(). Oh really? the stringLogger is a string logger? thanks.

Hi guys,

Hopefully this is the correct place to post this. After spending all of my 20s playing poker (successfully!) I am now doing a post-bachelor diploma in CS. This is a 2-year/condensed program for previous degree holders (my first degree is in History ) and provides all the essential CS and math classes with no filler/electives/bs. I'm now preparing to enter my first co-op term and am unsure if or how I should include my poker experience on my resume and in conversations with employers. I know this has been discussed on 2+2 ad nauseum, but I'm interested in hearing from those of you who are actually in this industry and/or have been through a similar situation. I don't have much else to put on my resume, except for a couple basic projects, volunteer experience, and a previous degree in an entirely irrelevant field, so I'm torn between empty resume vs controversial resume. Any advice?

This is like 0.1% of the benefits that a type system gets you...

Bump

One thing I really like about mongo is that search strings are json formatted, so they're very easily composable. If you have an existing query and you'd like to add a field to it, no prob

If you have a query and you want to make nested ors and ands, easy. if you want to extract a sub-query out of a query, super easy. No text parsing or munging required.

However the flip side is that the query language is very awkward for human interaction. I usually find myself having to go back and add braces and brackets, it's hard for me to write a complicated query from start to finish, unlike SQL.

Also, the pipeline stuff is hot garbage. Sorry.

But the main problem with it is that people try to use it to store relational data, and they shouldn't, because it's *so easy* to make new collections.

Mossberg, I think its an interesting fact and lots of people in the industry do too. I think the average programmer/tech worker has a better understanding of the math/theory of poker than the average person.

That being said, there are still lots of people that just think its gambling or don't approve/understand what you were doing.

I guess its probably one of those things where you increase your variance because some people will like it better than if you left it off and others won't like it.

Personally, I'd include it. Because even if it cost me a job it probably wouldn't be a job I'd want.

RB, I agree with most of that.

I think I also love it because its so seamless to use in python. We also use Java with Mongo, where its not as good.

well I make that observation operating on the assumption that you have unit tests and that errors from passing/returning wrong types are identified early and are easy to fix. When they're not easy to fix you have deeper problems where a type checking system wouldn't help you much more than good naming conventions.

just an opinion, i'm no authority on the subject.

I spent a lot of time early on in this bootcamp getting to know the JS iteration methods, now whenever I have a challenge in front of me, I feel like I always want to use a forEach loop.

Its nice being somewhat productive with crude tools and strategies, but I really need to expand my horizons and learn a lot more features.

Is Code wars a good way to practice stuff? any other suggestions?

A huge benefit of static typing is that it allows much more powerful refactoring support in the IDE.

Eg if you want to rename a method, the IDE can figure out exactly where in the project this type is used and automatically rename the method throughout the project, leaving all unrelated types untouched even they have methods with the same name and signature.

Absolutely this.

I hate doing a larger refactoring in Python.

larry, can you elaborate on what kind of things you want to learn or improve at? there are so many directions in which it's possible to expand...