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 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!
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
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.
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.
But why does that need to be tied to the framework? It seems that Elm provides two things that work together well: new language primitives and a functional framework. Tying the success of each component to the other doesn't seem like a great choice.
The Elm experience simply cannot work on JavaScript. It demands a pure, strongly typed functional language that guides developers from any background into the right direction.
I disagree, after all it's compiled to js. As I mentioned, cycle.js is a good example of a functional js framework. Perhaps the experience is much better with a typed, functional language, but saying it can't work without it is disingenuous and haughty. After all, this is how Angular works: the experience is much superior with Typescript, but you can use it with JavaScript if you really want.
It doesn't work like that in the case of Elm. You can implement the Elm architecture with React, Redux and Redux-saga, but that's just a poor imitation of the API.
The point of Elm is not just the architecture, it's the language that allows you to write robust websites with little to no debugging necessary, all maintaining that robustness no matter how much you extend, tweak and refactor the codebase without having to be an expert in the language.
"Zero runtime exceptions" is no exaggeration, it's a reality in practice guaranteed by the compiler, meaning "after all it's compiled to js" makes no sense.
I already told you, go use React, Redux and Redux-saga, Elm the framework makes little sense on JavaScript where you cannot enforce many of the constraints the framework is designed around and you'd be doing yourself a disservice by forcing it in.
In Elm you don't have exceptions, so the framework does not accomodate for them like, say, React does.
It's also a pure language, so the separation of main state mutation and other side-effects without Elm the language is nothing more than convention, so you're not doing any better than Redux+Redux saga on that point.
I'd suggest you try out Elm in a small project and see for yourself why it makes no sense to try to make it fit in the context of JavaScript.
Nope, that's not it either, since you can use Elm the language without importing Elm.Html ("Elm the framework").
It's simply that Elm the framework was designed without regard for the problems of other languages, and making full use of the features of Elm the language.
On the other hand, Redux was inspired by Elm to replicate the same model in JavaScript while accounting for the deficiencies of that language. The closest you can get to Elm is probably that.
No language that "compiles to javascript" really creates new language primitives - it would have to rewrite the interpreter to do that. What it does do - simulating new language features in javascript - could theoretically be done with a framework as well.
> Well then do you think no language that "compiles to machine code" really creates new language primitives, either?
No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor.
>The compiler can do compile-time checks that wouldn't be possible if it were implemented as a library instead.
Fair enough, but it doesn't actually change the grammar of the language, because those new "primitives" have to be implemented in, and interpreted as, javascript.
> No, because javascript isn't machine code, it's a high-level interpreted language. The metaphor of javascript as "bytecode" is just that - a metaphor.
This is a psychological distinction, not a technical one. There is no fundamental difference between machine code, byte code, or a “real” programming language. There were machines that executed lisp, and at the dawn of time people programmed in assembly. Heck, people programmed in machine code (punch cards) and assembly was a programming language!
Scala introduces a hell of a lot of “new primitives” over jvm bytecode, and type erasure compiles it all down to the jvm anyway. Or JavaScript, if you use scala.js.
This is, in fact, precisely what compilers do (or transpilers—again: psychological distinction, technically the same thing). That is their job, their function: translating from one language into another. As long as both are Turing complete, you can do anything.
Ten hours later and it's obvious from the all but unanimous negativity that I'm wrong about something.
But, I don't think the distinction is entirely psychological. Every numeric type is implemented in javascript as a floating point Number, that's all javascript has. New types aren't added to javascript when other languages compile to it, they're compensated for within the limits of what a javascript parser considers valid code, either through existing javascript types or facades which imitate types. Whatever Scala or any other language considers an Int, BigInt, Double, etc. must still be implemented as a Number when compiled to javascript, or some object which imitates the semantics of the original language. But an Int() object in javascript is still not an integer.
It doesn't make sense to say that languages which compile to javascript add anything to the language. Or maybe I just don't understand types, and they really do, and it really doesn't matter. But to me, the distinction seems to matter.
I should probably stop tilting at this particular windmill, though.
It's funny when languages like C where you have to baby-sit the memory handler "compiles" to JavaScript, where all memory handling is completely abstracted.
Just like no language that compiles to machine code can create new x86 assembler instructions.
So sure, what Elm gives you can be done with just a framework, but it wouldn't be very productive. There is a reason why hardly anybody programs in assembler anymore (unless they have a good reason). Higher-level languages provide better abstractions, allow you to write more expressive code, are safer etc.
A compiler takes input in one language and converts it to another language. That the web community has a fundamental misunderstanding of this and created a derivative word with the same meaning is unfortunate. That it is now being used in misguided pedantic arguments reflects poorly on our community.
The transpiler add-on in the comment wasn't meant to be meaningful anyhow. The main point were the compile time checks, which aren't to be achieved when using a library. Thanks for the correction though!
We paid for screenhero before they stopped charging. Last I heard, it was not as good as it once was now that it is part of slack. That aside, my work looked at going to slack and it was shot down vs staying with hipchat for a few reasons. Partly the cost of slack itself and partly the cost of chat bot rework (we have an unhealthy coupling of chat bots to hipchat that make it hard to migrate them to slack apparently). The bot(s) handle pr workflows, build jobs, internal service disruption comms, paging, and more.
The abstraction that hides mutable data structures is transient[1], not vars, refs, agents and atoms.
Those abstractions are all to do with mutable references, not mutable data. They're there to make sure that you have safe ways to coordinate state in concurrent environments.
I agree that immutability can be annoying in languages that weren't designed with it in mind, but the languages that were almost always make it easier, safer and performant to create copies rather than mutate data.
If you're writing Clojure or Haskell and you think you're going to save yourself time by "just creating a map and mutating its structure" then you're misunderstanding the purpose of the language. These constraints are what enable the guarantees and contracts those languages make.
But it does save time. JS is proof of that. There are no immutable data structures and the world rolls on. People will hate on JS, but it's effective.
You can learn to get into the "immutability mindset" if you train yourself to, but are you certain it's worth the time investment? It seems like there's at least a chance that it's not.
Sure, no arguments there. It does save time in JavaScript and a large part of that is because the language has been designed around mutability.
Part of that trade-off is that JavaScript can't make the same guarantees about what happens when you pass an object into a function. It's harder to be confident that a given program is correct.
Immutability is just a part of the "simple made easy"[1] ethos of Clojure and I think most Clojure programmers will argue that taking the time to understand that philosophy _is_ worth the investment.
Any bad implementation of something is bad. Sounds like immutability in JS is just badly designed and implemented, in a way that makes it difficult and slow to code with.
Don't generalise you're experience of a thing if you've only tried its bad implementations. Like don't judge Monads until you try them in Haskell. Don't judge immutability or DSLs until you try it in Clojure, etc.
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).