I think this is exactly what I've been looking for. I like going for walks and listening to audiobooks and podcasts, and I've been using Google's recorder as a way to "highlight" my findings, but it doesn't let me add to existing recordings so I can't collate sessions together.
I think you're not seeing it mentioned here because this is comparing apples to oranges. Node is not a web development platform, it literally IS only a runtime.
Rather than comparing with Django or Rails, one should instead compare it to Python and Ruby. There are several server side web framework for NodeJS also (Meteor, Sails, Express).
It's possible you may have confused Node with Express, as I see that happening very frequently, but Node is used for all sorts of other workloads like desktop apps, microservices, and other general computing tasks.
That's definitely one aspect of child rearing that every parent is (or should be) involved in, but young children often feel like they have to prove themselves to their parents. The end result is that they're usually only willing to learn things from their parents at a very shallow level.
I've struggled with that aspect of child rearing with my 6 y/o since she was able to speak. She is far more willing to learn at a deep level from teachers than from us, even though her mother is an experienced elementary school teacher.
One thing I noticed is when signing up with github, it requires read/write access to all repos. Does it write anything, or is that just the only access control github provides through the API?
The planning and project management aspect sounds like it's straight out of a post apocalyptic bureaucratic nightmare.
It was intended to be a strike drone, but wait, let's flip the project halfway through into an intelligence drone. You know what? f*ck it, let's flip it into a refuelling drone.
The project history is a sinuous cautionary tale of scope creep and descoping.
Positioning it as a tanker is a smart move. Taking on the least glamorous job helps keeping the scope down, lower expectations, provide value from day 1. It's what they should have aimed for in the first place.
While you might be right, is it not also possible that they delivered some key capabilities that were unique (autonomous carrier landing!?) to reach the strike objective, realized it wouldn't meet all of them so pivoted to ISR (of which I recall there being a shortage of assets so maybe more demand with other strike programs going on in 2012?) then looked to the tanker mission after realizing there were other things that it maybe couldn't do as well as other platforms for the ISR purpose?
In startup language you might say the team "pivoted"?
I'm not saying that's what happened here as bureaucracy often causes these nightmares, but it's possible there were a lot of good intentions / approaches at play as well.
Where did they announce that? I still have that setting enabled, and I'm using it for backing up exactly the same way you described, so I really hope this doesn't just get magically turned off someday.
IIRC from when I looked into it and got it working a few months back, you npm install bucklescript, wihch gives you a compiler to convert reason to JS, so to do any testing that actually includes a real world equivalent experience (such as include it in a sample webpage, maybe with React), you're talking about using webpack or something to bundle all the dependencies and steps into a deployment procedure.
Since it compiles to JS, and uses a JS lib and ecosystem to install the utilities that do the cross-compile, it's sort of like if to try out Python you had to first download and install a C compiler and C libraries used in Python, and compile python from scratch, just to try it out, because no pre-existing binaries, packages or installers existed. If that was the only way to try out Python (or Ruby, or Perl, or anything), you would get a lot less people trying it out, and a lot less willing to go through all that in their build chain (in case python updates, right?) if easier alternatives exist.
Just because your language compiles to another language, that doesn't mean to you get to ignore the on-boarding experience to that extent. At least not if you really want to succeed.
There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build – frontend, backend, native, or some combination thereof.
> There's no ignoring going on. Reason exists on its own because it's not opinionated on what sort of app you're trying to build
I think either I wasn't clear, or you completely misunderstood me. My point, that Reason should have a standalone installer or package that gives you a working Reason as simply as possible without a whole build infrastructure required, is only bolstered by this statement.
I don't think it matters if it's the Reason-to-Ocaml targeted, or Reason-to-Javascript, or one for each, or one that includes both. Having to install one language, and then use tooling and package managing from that language to install another, strikes me as somewhat ridiculous in this day and age. just ship the entire tooling stack abstracted away.
No, I'm complaining it's not optimized for the person that just wants to try it out in any way. Not everyone is using npm or already has Ocaml on their system. Making them install that entire toolchain first to try our Reason locally, is sort of crazy, it's just not the crazy that's easily seen when the costs are already completely amortized because you're a Javascript or Ocaml programmer already.
And locally is important, since they might want to try a simple app with it, and not want to set up a whole Javascript dev toolchain with webpack. Sure, they might end up going that way eventually, especially if they choose Reason and or React and integrate it into their project, but for a test drive, requiring it is a large hurdle and a lot more to keep track of.
Reason's current distribution method is akin to Python requiring the installation of a C compiler toolchain so you can download the source and compile. To be sure, that's a wanted distribution method of an open source project like that, but they've rightly recognized that as the only distribution method it would hamper adoption, especially on platforms where that toolchain is harder to get set up.
I'm not even suggesting Reason go as far as that, exactly. I'm suggesting Reason ship a tarball/zip with a directory structure that includes Node and a set of pre-installed packages that provide Reason/Bucklescript. Installation instructions would include setting a few environment variables (altering PATH, telling Node where to look for packages). Or instead of Node/npm, provide Ocaml/OPAM with the correct packages pre-installed (although that might be slightly harder due to an increased amount of binaries as opposed to interpreted scripts as with JS). Or both in the same package, if it's not an excessive amount of work.
I understand it's a lot of work, but at a certain point, expecting prospective users to install a whole toolchain not for your language, but for the hosting language, just so they can test it out your language ends up being limiting. You've said that Reason isn't trying to be opinionated in what kind of app you're trying to build, but I think it's still being very opinionated in the exact process required to build that app. It's just that you allow for two opinions instead of one.
Hopefully that's clear enough, and you understand this comes from an actual desire to make Reason better. I spent a couple weeks in my spare time earlier this year evaluating whether Reason would work well for a new project I was starting, and I was extremely excited by the possibility of a shared front-end/back-end codebase that could be compiled to binaries when needed for performance reasons. That ended up not working out because I think the ecosystem isn't quite there yet for that exact need (e.g. a good framework and ORM that's mostly in Reason, and doesn't require converting from Ocaml to reason, etc), but a big takeaway I got from that was that as someone not invested in the Node module ecosystem that much, setting that up, and in a way that was repeatable and documented, is painful, and that ended up counting against Reason in the end because I would undoubtedly have to deal with that. That's not to say I wouldn't with what I'm proposing, but if I'm already on the Reason cheer squad that's less of a problem, language adoption-wise.
Everything I've heard suggests ReasonML is targeted primarily at developers currently using NPM and working in that stack. I don't think creators of a tool have a moral obligation to make it easy to use for everything. Most things have an intended focus, and some happen to be really good for all kinds of other stuff too. That being said, it does sound like it would be cool for it to be easier to install without that dependency.
FWIW, Scala and Clojure require the JVM to work at all, and both are pretty popular.
You think that's bad? My damn BANK has the following password policy for online banking:
The password you create here can be used to access Online, Mobile and Telephone Banking.
All passwords must be six characters in length. Special characters (eg. *, %, $, etc) will not be accepted.
Banks are some of the worst - though oddly in many cases I've seen them support much more complex usernames than passwords. If you use a password manager you can generate large, random usernames to go with your tiny, weak password, potentially.
Send it in a certified letter. Address it to the CEO and send certified CC's to the FDIC, CIO, and a reporter for a local or national tech newspaper column.
It may sound archaic but you have to raise the visibility if you're concerned about changing the banks behavior.
I've noticed the opposite pattern in my house. Ever since we bought the place, we noticed that occasionally we would semi-randomly get a very fishy smell coming out of our staircase, and couldn't find the cause.
After putting my google-fu to use, I realized it was the plastic casing of a small light fixture in the staircase that was getting very hot and slowly melting around the incandescent bulb.
I've replaced the bulb with an LED bulb several months ago and I've checked the base of the socket, the fixture, and the bulb after hours of use, and all three are barely warm to the touch at all.
I suppose it may depend on manufacturing quality, or as the OP article mentions, airflow.
I'll be trying this on as a replacement.