You can get a really, _really_ good pair of professional studio monitors for 2000$. I'll confess that I've never heard the HP1 but that is a bold claim!
HN user
brunoc
grokking some really weird junk http://js-montreal.org
My 2c as a JavaScript senior citizen --
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
It's kind of like needing to wear glasses; all you know is that everything looks blurry, and as far as you know that's how everyone sees. And if you struggle to see clearly, well, that's your problem.
My guess is that it stays undiagnosed because doctors aren't trained to make the connection between untreated ADHD (as an adult) and the disparate consequences it has on one's life.
Developers model and reproduce this drift in software synthesizers because it's pleasing to the ear of many...
"Don't hate the player, hate the game"
There can be a lot in-between here. You might end up with something like `Report(type: PROFIT_AND_LOSS, unit: MONTHLY, segment: SECTOR)`
Like every tool, there's a sweet spot where it really shines and others where it doesn't fit. If you need to have access to a bunch of disparate datasources it's really nice to have that layer of abstraction.
I feel that by using these types of tools you could really miss out on a fantastic opportunity to create a schema that models the business domain as accurately and elegantly as you want to make it, regardless of the underlying service topology or the databases behind it.
That's what I find the most attractive about GraphQL. Large companies and companies that have grown fast often have all kinds of APIs made at different time by different people with different standards. GraphQL lets you paper over that without breaking existing, revenue making code.
Wouldn't you be spending the money you save on salaries on training your new "reverse bootcamp" employees? Hiring entry level people and giving them work isn't the same as teaching. The costs involved in actually training them has to be paid from your own pockets after all.
Might be possible to have them sign an employment contract beforehand and simply have them join an existing, reputable bootcamp.
Same as sibling comments, and I would add that if you’re interested in modular fun, there is now a Volca Modular and in a slightly more expensive bracket, the Behringer Neutron has a ton of features for the money.
A good way to start is taking a piece of music you like and trying to reproduce a reasonable facsimile. Going top down like this gives you some insight into the structure of music without having to start from “first principles”.
How? This is a tiny functional CSS library.
A lot of modern CSS frameworks choose to ignore the cascade.
This trend has grown in response to how difficult it is to avoid regressions at scale - large or multiple projects, lots of components, lots of independent teams, etc.
The cascade really is an elegant and efficient idea but it becomes really difficult to manage as projects grow.
The different with inline CSS is that those helpers are the building blocks — that’s where your standardize your design system metrics.
As others have pointed out this library provides a mechanism to abstract into components as well.
Ah yes, the slippery grope fallacy.
Very similar situation in Montréal. Handful of SV companies with offices here, a few success stories, and everything else far far below in terms of compensation.
I stole this from someone else, but I can’t remember who. BBT is what stupid people think smart people are like.
Critical for the survival of many businesses? Dealing with important data and processes? In that sense. Not in a system-critical kind of sense (kernels, etc).
I mean I'm glad that when I call 911 the dispatching system probably isn't written in JavaScript, but it's likely that there's a web ui somewhere in there. Police cars too, run web applications on those touchscreens.
I'm definitely aware of JS shortcomings, having had to deal with them for many years. I just found that particular quote to be a little snarky, and outdated.
JavaScript has a bad reputation, but in reality is a good language for what is was designed for: quickly write small scripts.
That's a little condescending, considering the amount of non-trivial, critical applications written in JavaScript. And it ignores the progress made on the language and tooling of the last oh i don't know, 20 years.
Well, you can always find a reason to buy a new synthesizer. That works in the favour of the manufacturer.
Computers, not so much.
Source: Also collecting synthesizers. :)
You are comparing a beautifully minimal web library (Sinatra) to an abominable horror from the very depths of hell (Wicket).
It is at best an inappropriate comparison.
Maybe where you work. Not expected everywhere at all.
We hire a lot in Montreal. Mid-size startup. Range is more like CAD 85-140k for generalist frontend and backend developers.
In the larger cities, salaries have really gone up in the last few years.
Doing exactly this right now on a new project using Preact. Working great so far.
I hear this a lot, but I don't get it. How would this help make things simpler or stop "this madness"? If anything it opens up the possibility for even more crazyness. The only difference is you (maybe) get to pick your favourite language instead of learning new ones.
That's consistent with my experience with a very DRY Sass library. If the consumer needs flexibility, such as different themes or new context for components it quickly becomes impossible to manage dependencies and abstraction begin to leak.
CSS tooling is quite rudimentary, too, which doesn't help.
The last scenario you outline has a lot in common with the Strangler Application pattern: http://www.martinfowler.com/bliki/StranglerApplication.html
CS61 at Harvard covers that stuff, building your own shell (and memory management, etc) in C and it's an introductory class. There is a lot of hand holding of course but I really loved that class.
I'm just about to start a course that uses OCaml for teaching. Any book or website recommendations?
The textbooks are "OCaml from the very beginning" and "More OCaml: Algorithms, Methods & Diversions"
Another thing that may change this in the future is proxies and "method not found" type of functionality in JS.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But if people are concerned about syntax mangling now, those features are going to make things 100 times crazier.
For those of you like me who spat their coffee reading this, you can find additional information about this anecdote here.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Or for those more fond of sport analogies, practicing 3-pointers over and over again. It's a very small part of the whole game and you need to excel at all the other skills required to be a great player. But I disagree with the blanket statement of OP that it doesn't make you a better player.