HN user
[ my public key: https://keybase.io/danprince; my proof: https://keybase.io/danprince/sigs/8AYDk4-RDKmDfqhI3Zvr4m2aPQy1DeZ86fGOs6WbGLU ]
Sorry for the Kumu 500s! I moved some critical parts of our service away from EC2 classic on Saturday morning. One of our servers was accidentally recreated with an 8GB volume instead of 1TB and the HN hug caused a process to blow through the remaining disk space with indexes. Should be back to working order now!
This feels a lot like Vim's built in file explorer (netrw).
I find these kinds of text based, keyboard centric explorers to be far superior for navigating around a codebase, then giving you back your screen space as soon as you're found what you're looking for.
I implemented something similar but for VSCode: https://github.com/danprince/vsnetrw
Kumu | REMOTE | Full Stack Developer | Full-Time | kumu.io
Building network & viz tools for tackling complex problems.
React, TypeScript, Rails, Node, Postgres, CouchDB, AWS. We're currently undergoing an ambitious modernization process for our main codebase, and looking for engineers who like a challenge.
Bonus points if you're happy getting your hands dirty with AWS, Linux, and virtual machines.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Kumu | REMOTE | Full Stack Developer | Full-Time | kumu.io
Shit's broken, and we're trying to fix it: https://kumu.io/manifesto
Looking for enthusiastic developers to help us build tools for tackling complex problems.
React, TypeScript, Rails, Node, Postgres, CouchDB, AWS. We're currently undergoing an ambitious modernization process for our main codebase, and looking for engineers who like a challenge.
Bonus points if you're happy getting your hands dirty with Linux, Packer, and virtual machines.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Doesn't feel unreasonable to conflate the two. npm is the dominant way to handle dependencies for frontend and backend, even some of the most popular script-tag delivery CDNs are powered by npm (unpkg, skypack).
Coincidentally one of my previous posts was about a no tool approach. https://danthedev.com/web-dev-without-tools/
Why is it great to be able to publish a package quickly? You may be a smart programmer who only releases production quality, bug-free, vulnerability-free code, but is it a good thing that it is easy for inexperienced developers or malicious users to be able to publish packages at the same ease/speed?
No one wants an ecosystem with only jQuery, but there's a middle ground somewhere before you get to 2 million packages. Competing frontend frameworks fit comfortably within that space. I just don't want a world where there are 16 competing packages that all implement a slider in React.
There's a huge difference if you only use npm for personal projects, too. The consequences of picking unmaintained/undocumented/insecure/buggy software are much, much lower if you can afford to rewrite/throwaway in a weeks time.
I don't think we talk enough about the downsides of DRY.
Reinventing the wheel for the sake of reinventing the wheel (not-invented-here) is a problem, but reinventing it for the sake of learning more about wheels is a big deal.
I suppose many developers reach for libraries because they're more confident that the libraries will implement things correctly/more efficiently than they could. But if they keep reaching for libraries (instead of trying to write an `isEven` function themselves) then they never really improve either.
Give better cues that we are in an asynchronous mental model
The `async` keyword(!) is objectively a clearer signal that the code in question is asynchronous. That's why type-checkers use it to prevent you from doing dumb stuff like awaiting in a synchronous function.
In simple cases express the code at least as cleanly as async/await
It's pretty hard to see much of an argument here. How can the promise version ever be seen as "at least as clean"?
await someTask()
// vs
someTask().then(() => ...);
Provides a much cleaner option for more complex workflows that include error handling and parallelisation.
If you've somehow come to the conclusion that `Promise.all` doesn't work with `async/await` then you have probably misunderstood the relationship between `async` functions and promises. They're the same thing. Want to parallelise a bunch of `await` statements? You can still use `Promise.all`!
I do occasionally find try-catch to be awkward, but that's because it creates a new lexical scope (just like promise callbacks do). I also think the consistency from having one unified way to handle errors in sync/async contexts justifies it.
My take is that the lack of experience for the average JavaScript developer is absolutely a factor here. I don't think it's the only factor though. Here are some of the other pieces of the puzzle.
JavaScript's standard library is so thin on the ground that there's already a culture of "reaching for a library" to accomplish tasks that many languages do out of the box.
The monoculture is wide enough that the language caters to lots of paradigms and schools of thought. If there's one library that uses classes and method chaining, you can be sure that another will pop-up to re-implement the same functionality in a pure functional style. One will focus on type safety and another will abuse the dynamic bits of the language to make the code you write as terse as possible.
Amount of code shipped has always been a more important metric for JS than other languages because the nature of the web means that users have to wait whilst the source code is downloaded before your page becomes interactive (for a huge class of applications). This encourages developers to favour smaller libraries that solve for narrower problem domains.
It's become very trendy to write a smaller, faster, better, smarter version of existing libraries. The JavaScript community loves the process of picking a catchy name, registering a domain, designing a logo, and publishing packages as though they were businesses. This creates an abundance of packages that look great on paper, but with no users, patchy/non-existent tests and maintainers that haven't ever used the code in a professional context.
Finally, I think JavaScript is a deceptively simple language. It doesn't take very long before people (mistakenly) think they're close to mastering the language. By comparison, contributing to an open source project in a meaningful way is quite difficult, so these developers assume that other libraries must be written badly if they find it hard to contribute. Then they write their own, because they believe they can do a better job.
The ecosystem as a whole sees a lot of innovation, and pays for that with a lot of churn and a lot of dependencies. From a theoretical standpoint, it's a fascinating corner of modern programming. In a professional context, it horrifies me and I wish I could sanely cut npm out of the chain.
Tried git worktrees? https://git-scm.com/docs/git-worktree
Also a climber, and occasional soloist. You can absolutely make a bad move on a solo and not die.
The soloists who achieve notoriety are either pushing the limits, or seeking adrenaline, which skews the stats, especially when you check the number of them that passed doing non-climbing activities. It's not particularly fair to compare that demographic to the average folks who bike in traffic every day.
Soloing well within your limits is like riding a bike on a quiet road, there are things that can go wrong, but something extraordinary has to happen for it to be serious.
Soloing close to (or outside of) your limits is like riding a bike on a busy motorway. The margins for error disappear and mistakes are far more likely to be fatal.
I don't know of a JavaScript implementation where that approach would work. A synchronous implementation of `sleep` can't yield control back to the main thread to handle the asynchronous stuff. You'd just end up polling indefinitely.
There's no performance benefit. Promises/callbacks are abstractions which live in a much higher level programming space.
Incidentally, many high level programming languages _don't_ include GOTO, because people find it needlessly confusing and inhuman.
Go watch Jorbs play (the author). In particular his "over-explained" runs on YouTube are good for getting in-depth breakdowns.
There's a bit of an unavoidable learning curve initially in learning the cards in each deck, because so much of the strategy comes down to analysing what your deck can currently do, and what adding (or not adding) a card to it will change.
That wasn't supposed to read as a criticism of Redux. Redux was just popular enough to be the medium where people discovered that you pay a price for the indirection you need to keep view and state separate.
It won't ever be a one-size-fits-all solution and unfortunately, Redux will have to live with the legacy of plenty of users finding that out the hard way.
That being said, I think Redux Toolkit is a great improvement to the vanilla experience and I'm always impressed by how much I see you out and about on the internet weighing in on these kinds of threads. Inspiring stuff!
I would go one step further and say that the counter-movement is the visible effect of newcomers discovering that separation of concerns was a bad decision for the simple apps they were building.
Or maybe more accurately, discovering that it's often simpler to separate by concern at the component level, than at the app level.
We all ride the pendulum until we find the shade of grey which works best for us.
Maybe overwhelming was too strong, but I don't see many people getting excited about building new projects with Redux any more. Presumably some proportion of that 1/3 are stuck on Redux, unwillingly?
I like (and use) Redux on a daily basis, and I don't think it's a sensible choice for lots of React apps. Maybe the overwhelming rejection that I've witnessed is people discovering that they used it for stuff they shouldn't have.
This isn't a solved problem.
The React ecosystem has spent the last few years trying a model where the application layer separated from the view layer with a pure functional state management solution called Redux. The overwhelming response? People didn't like it.
Decoupling systems is a trade-off. Pull your network requests out of your components and you have two bits of code that are easier to test. Indirectly, the component is still going to call that code, and it's up to you to manage the complexity of that indirection.
Not every application needs separation of concerns, and in many, colocation of concerns reduces the cognitive burden, because you can reason about components in isolation. To me, that's a more powerful guarantee than a function being strictly pure.
Kumu | Kumu Enterprise Developer | https://kumu.io | REMOTE | Full time | Kumu is a data visualization platform that helps people understand complex relationships, primarily through network, systems, and stakeholder maps.
Shit's broken, and we're trying to fix it: https://kumu.io/manifesto
We’ve worked with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, 100Kin10, Democracy Fund, World Bank, Humanity United, and more.
We're looking for an experienced developer to join our team to lead development on Kumu Enterprise, a parallel release of our product that runs in on-premises virtual machines.
Experience with Linux, Packer, VMWare and AWS is ideal. Bonus points for experience with (or willingness to learn) Rails, React, and TypeScript, for working on the product itself.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Full job description: https://kumu.io/careers
Kumu | Kumu Enterprise Lead Developer | https://kumu.io | REMOTE | Full time |
Kumu is a data visualization platform that helps people understand complex relationships, primarily through network, systems, and stakeholder maps.
We’ve worked with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, 100Kin10, Democracy Fund, World Bank, Humanity United and more.
Check out our manifesto to understand what we're about: https://kumu.io/manifesto
We're looking for an experienced developer to join our team to lead development on Kumu Enterprise, a parallel release of our product that customers run in virtual machines on premises, or on dedicated servers in AWS.
Experience with Linux, virtual machines, AWS, and an understanding of networking is expected for this position. Additionally experience with Rails, React, and TypeScript is a large bonus, for working on the product itself.
We're a small and flexible remote team who place a lot of value on physical and mental health, great lifestyles, and doing meaningful work.
Full job description: https://kumu.io/careers
What makes the Date constructor a good candidate for the standard library but not the aforementioned methods? Not everyone knows about Day.js, you had to learn that at some point. Why Day.js instead of Moment or Luxon or Date-Fns? There's a lot of cognitive value to having a fully featured standard library.
As I discovered yesterday, :Gbrowse also works for other contexts such as jumping directly to the GitHub page for a specific commit after opening one via :Git log or :Git blame.
As someone who has written tens of thousands of lines across both ClojureScript and TypeScript, this baffles me. I can definitely understand why someone would prefer CLJS, but it has a way higher barrier to entry than TS.
If you're smart enough for Clojure then you're smart enough for TypeScript. That doesn't mean you have to like it though, but you don't have to hide that distaste behind incendiary exaggerations about TypeScript only being suitable for superhuman geniuses.
The overwhelming evidence is that TS is popular _because_ it is a safer and easy-to-understand alternative to JS.
We set off building a new product using this approach a few years ago and wrote about our motivations here: https://medium.com/hackernoon/exploring-single-tenant-archit...
I can't remember all of the reasons that we ditched the idea, but it quickly became clear that we would be writing a lot of the core tooling ourselves, and we kept running into problems with AWS around dynamically provisioning the load balancers and certs for N boxes.
I wouldn't dream of trying to manage different schemas across all the databases either, that sounds like a serious headache that could only be mitigated by having separate codebases and separate development teams managing them.
If a customer needs custom fields, I would make them a first class citizen and the required `fields_definitions / field_values` tables to your database and let them manage those fields themselves.
I'm glad we ended up defaulting to a multi-tenant architecture even though we lost some of the proposed benefits (isolation, independent scaling etc).
Kumu | Remote | https://kumu.io
Kumu is a web-based data viz platform that helps people understand complex relationships, mostly through network, systems, and stakeholder maps. We’ve spent years refining Kumu’s visualization platform, and we’re embarking on our next phase: developing a suite of specialized tools for tackling tough problems (such as building stronger communities through Weavr, building better teams through Compass, and collecting better data through Undercurrent and System Effects).
Full-time position (remote)
Salary $60-80k
Equity 1-2%
Small, bootstrapped, and profitable team with recurring revenue over $300k / year
Flexible hours with a fun mission-driven team
Modern stack: react, typescript, ruby/rails, aws/cloudformation, postgres, bonus points for experience with: ui/ux design, react-native, webgl, apollo/graphql, koa, webpack, babel
On a day-to-day basis you’ll primarily be working with Ryan (@rymohr) and will be involved throughout the entire development process: from the initial brainstorm to flush out the basic architecture all the way to the final stages of testing and release. We like to move fast and ship often, and we try to break work into weekly deliverables to keep everyone’s expectations and progress in check. We do a quick hangout at the beginning of each week to revisit everyone’s immediate priorities.
Once a year the whole team gets together for an adventure, with past retreats including snowboarding in Oregon, surfing in Hawaii and rock climbing in Colorado.
If you're interested, please send an email to careers@kumu.io with answers to the following prompts:
1. Tell us a little about yourself. Who are you? Where do you come from? What skills have you mastered?
2. Tell us about a project you’ve worked on that you’re proud of
3. Include links where we could learn more about you professionally and personally (website/github/twitter/medium/instagram/etc)
4. Include a recent photo of you doing something that you love Thanks!
And 997 of those are development tooling dependencies that are not included in the application that you eventually deploy.
Don't get me wrong, I would rather there were fewer development dependencies too, but they are tooling abstractions that you are _opting-in_ to.
If that is still a cognitive burden, then there's nothing to stop you using React a build step through a CDN.
Kumu.io | Full stack developer | REMOTE | Full time | https://kumu.io
Kumu is a web-based data viz platform that helps people understand complex relationships, mostly through network, systems, and stakeholder maps. We’ve spent years refining Kumu’s visualization platform, and we’re embarking on our next phase: developing a suite of specialized tools for tackling tough problems (such as building stronger communities through Weavr [1], building better teams through Compass [2], and collecting better data through Undercurrent [3] and System Effects [4]).
We’re currently working with some of the world’s top organizations including The Omidyar Group, Gates Foundation, Hewlett Foundation, USAID, Stanford ChangeLabs, Democracy Fund, World Bank, Humanity United and more.
· Full-time position (remote)
· Salary $60-80k
· Equity 1-2%
· Small, bootstrapped, and profitable team with recurring revenue over $300k / year
· Flexible hours with a fun mission-driven team
· Modern stack: react, typescript, ruby/rails, aws/cloudformation, postgres
· Bonus points for experience with: ui/ux design, react-native, webgl, apollo/graphql, koa, webpack, babel
On a day-to-day basis you’ll primarily be working with Ryan (https://twitter.com/rymohr) and will be involved throughout the entire development process: from the initial brainstorm to flush out the basic architecture all the way to the final stages of testing and release. We like to move fast and ship often, and we try to break work into weekly deliverables to keep everyone’s expectations and progress in check. We do a quick hangout at the beginning of each week to revisit everyone’s immediate priorities.
Once a year the whole team gets together for an adventure, with past retreats including snowboarding in Oregon, surfing in Hawaii and rock climbing in Colorado.
Please send an email to careers@kumu.io if you’re interested or know somebody we can reach out to who might be. Thanks!
I love the idea of Parcel but I've struggled with a number of non-obvious problems when using it on hobby projects.
° Sourcemaps not working (wrong files / no source translation)
° Randomly losing exports (a module with multiple exports where one of them ends up as an empty object - fix by clearing cache and restarting)
° Errors like "module 71b not found"
° Hot module reload enabled by default, meaning that all top level code runs again when you reload the code (e.g. here's an extra canvas in your dom)
My preferred zero config setup for hobby projects has become <script type="module">[1] and a live reload server[2].
If I'm working on a React project then I will always use Create React App when I can[3].
When I take something beyond the hobby stage and into maintaining it as an ongoing project, I use TypeScript Quickstart[4]—to abstract the underlying Webpack config and start writing code immediately.
I'll only reach for Webpack when I know that I need more flexibility than any of these other tools offer—which isn't very often.
[1] https://jakearchibald.com/2017/es-modules-in-browsers/
[2] https://github.com/tapio/live-server
There are actually a lot of great materials available on Systems Thinking, here are a few of our favourites:
Articles:
- Introduction to Systems Thinking (https://thesystemsthinker.com/introduction-to-systems-thinki...)
- Tools of a Systems Thinker (https://medium.com/disruptive-design/tools-for-systems-think...)
- The Mythical Leverage Point (https://blog.kumu.io/the-mythical-leverage-point-d582ce4b8b4...)
Videos:
- Peter Senge Introduction to Systems Thinking (https://www.youtube.com/watch?v=eXdzKBWDraM)
- I Used To Be A Systems Thinker (https://www.youtube.com/watch?v=3Ymt_TbNNwE)
- The (Failed) Promised of Systems Thinking (https://www.youtube.com/watch?time_continue=614&v=aelqgvFXGi...)
- Systems Practice Mindsets (https://vimeo.com/212281432)
Courses:
- +Acumen Systems Practice Course (https://www.plusacumen.org/courses/systems-practice)
Books:
- Thinking In Systems: A Primer by Donella Meadows (https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp...)
- Fifth Discipline Fieldbook (https://www.amazon.com/Fifth-Discipline-Fieldbook-Strategies...)
- Systems Thinking for Social Change (https://www.amazon.com/Systems-Thinking-Social-Change-Conseq...)
Articles on Leading Systems Change:
- Dawn of Systems Leadership (https://ssir.org/articles/entry/the_dawn_of_system_leadershi...)
- Acting and Thinking Systemically (https://thesystemsthinker.com/acting-and-thinking-systemical...)
- Transforming the Systems Movement (https://thesystemsthinker.com/transforming-the-systems-movem...)
Relevant Tools and Websites:
- Kumu (https://kumu.io) - Web-based tool for building interactive system maps.
- The Systems Thinker (https://thesystemsthinker.com/) - Complete library of all "The Systems Thinker" publications over the past 30 years
- Loopy (http://ncase.me/loopy/) - An playground for building interactive systems maps.
(Disclosure: I'm a Developer at Kumu)
I did last year's Advent of Code[1] using a different programming language for each day of the month.
Repl.It was easily the best tool out there for quickly prototyping solutions and testing them out for the languages that I don't use often and don't have a dedicated environment set up for.
As part of that month, I started tracking each of the online REPLs I ended up using and threw them all into a gist[2]. Turns out you can do a lot of programming from the browser these days.
[1] http://adventofcode.com/2017
[2] https://gist.github.com/danprince/0f4a200319c95209c9c028b296...