For the most part, JavaScript doesn't need a build system, so from a practical standpoint npm is its build system. Most JS projects shouldn't require anything more complicated than npm install to put them in the proper location. Now you can argue for something like a minifier, and things like Typescript add a wrinkle (as it actually does need a build system), but all that should still be able to be handled by npm.
I'm curious how you would use Make to install dependencies. I'm aware of Guix, but that's probably an extreme example, most people probably aren't willing to sandbox literally their entire OS install, plus it's entirely unreasonable to require a particular OS in order to handle dependencies of your project. It shouldn't matter what OS I'm using (within reason), the project should have an automated way to install any dependencies it requires.
Here's the thing with Make, even if used only as part of a build system, it's both too complicated, and not complicated enough at the same time. The makefile format when used very sparingly isn't too bad, but once you pass needing more than 2 or 3 rules it gets unwieldy, and on any significantly sized project it will need more than 2 or 3 rules. Using autoconf and automake just proves the point, now you're using a build system to build your build system. Autoconf in particular is way too complicated, and an absolute nightmare to try to extend or customize.
Instead of using a tiny little sliver of make as essentially build system glue to connect the actual build tools together, why not just use slightly more powerful build tools and get rid of make all together?
That's a rather dated view of what a build system should be. Most developers these days don't want to have to manually install all of a projects dependencies in order to build it. More importantly, there's also been a push towards wherever possible installing dependencies into sandboxes to try to prevent things like DLL hell, which isn't possible if you install dependencies at the OS level. I much rather just check out a project and run its build system to fetch all the dependencies instead of what we used to have to do with C projects, which is go read the docs to find the list of mandatory and optional dependencies, then go look through the distribution package manager to try to match up package names with library names (including a few head scratchers where something is included inside of a differently named package), and finally install the whole mess and hope that the projects config script properly finds them all.
That last bit is really key. Nearly every modern build system is also a dependency management system, something that really isn't possible using Make. There have been tools introduced to address that particular need for C/C++, but they integrate poorly if at all with the build system, so it turns all your builds into (at least initially) three step processes of run dependency installer, run config tool to figure out exactly which flavor of C compiler/linker/etc. to invoke, run make to actually build the thing.
It's also possible to do some truly awful things with make. I once worked on an embedded device that the SDK provided by the OEM was written using a truly horrific makefile system. There were no less than 80 makefiles all tied together to build an entire system image, including the building of the linux kernel, all the bintools, and a bunch of other custom stuff the OEM provided. Trying to understand, much less modify any part of that build system was an absolute nightmare, and is one of the few times I've actually wished they had used shell scripts instead of make for some of that stuff.
As for Maven, it was quite a pioneer in its day, but it hasn't aged well, in particular being written in XML which just adds needless verbosity. For a more modern take, look at Gradle, which provides everything that Maven does (and uses mavens dependency system), but is a lot more flexible because it's a DSL for project building instead of a declarative system like Maven.
I was kind of disappointed this wasn't on a modern processor. Finding a way to hack microcode updates on a modern Intel CPU would be HUGE, both as an attack vector, and because the Intel ME unit is a binary black box that prevents any modern Intel CPU from being completely security audited.
Another bit about the SR-71 (and supposedly concordes) is that their structures are designed with tolerances based around the forces they experience at speed. The effect of which is that when sitting on the ground not going anywhere there are gaps between some parts, and others are tightly compressed together (and then separate while traveling at speed). I don't remember if it was the last concorde, or one of the SR-71s, but there's a story out there about the pilot on its final flight sticking his hat into a gap in the cockpit, which on landing promptly closed up permanently sealing his hat in place inside of the cockpit (he did it on purpose to commemorate the last flight). Similarly there are stories out there that claim the SR-71 leaked fuel like a sieve while sitting on the ground because it needed the atmospheric heating from going supersonic to seal up all the various fittings in its fuel system.
It's a fair point, but by the same token it's usually easier to teach a backend dev good UI design principles, than it is to teach a mediocre frontend dev good programming principles. There's also the fact that for a lot of the kinds of work we're hiring for, there's a creative team producing design documents that the developers are working against, so they don't actually need good UI skills generally (although it certainly can help, particularly when the designers produce things that don't actually work in practice).
Yes, it's in many ways exactly that popularity that's the problem. The ratio of good to mediocre programmers hasn't really changed any, but now there's a whole lot more JS devs out there, so finding the good ones is an exercise in wading through a sea of mediocrity. For better of worse, the Java developer ecosystem does a better job of filtering out the mediocre devs, and generally once you reach a certain level of experience picking up something like JS becomes a trivial exercise. We tend to favor candidates that have experience in multiple languages because it's a strong signal that they're a quality developer, and you tend to find more of that in your backend developer pool, where the frontend developer pool tends to have a lot of experience with a ton of frameworks, but they're all almost exclusively pure javascript focused.
Part of what's missing is that separation of concerns doesn't mean not mixing code and markup, it means not mixing your business logic with your rendering logic. One way of enforcing that is to put your rendering logic into a straightjacket and restrict it to very very simple primitives, nothing more complex than a simple for loop over some indexed value or a very primitive form of if/else statement, which is basically what most of the templating systems do. That forces you to keep your business logic out of the view logic because the view rendering system simply isn't powerful enough to express most of your business logic.
It turns out though that when you do that, it becomes really hard to express some more complicated (but perfectly valid) view logic, and then you end up moving a bunch of your view logic down into your business logic which is the same problem, just in the other direction. JSX takes the straightjacket off and gives you the full power of JS to express your view logic. Yes, it also opens the door to let you do bad things like in-lining all your business logic inside of your views, but realistically nobody is doing that, and the framework strongly discourages doing things like that.
Ramp up time shouldn't be the only consideration, in any moderately sized project ramp up time will be dwarfed by other concerns like ease of development. In general, ramp up time is one of the weakest arguments in favor of anything you can make and should only be taken into consideration after all other concerns have been shown to be moot. Likewise the argument about "finding devs". Any competent developer should be able to come up to speed with most anything mainstream relatively quickly, and in the case of junior devs they're often far more willing to invest in learning whatever niche technology you've selected. The quality of developers you hire should be a much larger concern, not the quantity.
As one data point, a number of years back when we needed to hire some frontend developers we actually advertised for Java developers because when we looked for JS devs the quality of candidates we got was abysmal. For another data point, when one company I worked for needed to hire Flex developers (this was a number of years ago) they once again advertised for Java developers, and when I responded asked if I was familiar with and/or willing to learn Flex, which I was. It took me about a month to fully come up to speed with Flex, and I was productive in it within a week.
As someone who both interviewed bootcampers, and also partnered with a local bootcamp (IronYard) this is pretty much exactly my experience. The bootcamps can take someone who had an interest in programming before hand, and give them a fast leg up to get into programming professionally, and that's great. But the vast majority of people in these programs are just there because they heard you can make a lot of money as a programmer and have no real interest, or talent with programming, and it shows in their work.
Because the academics ultimately drive the commercial, there's just such a delay between the two that the relationship isn't always obvious. Just take a look at Java, one of the most widely used programming languages for commercial development. It's hardly cutting edge, but if you step back and look at the way the language has evolved it's slowly been integrating all the design choices that have come to the forefront of academia. Generics? Check. Lambdas? Check. Streams? Check. Reactive design? Check. Non-nullable values? Eh, sort of, half marks there. Immutability? They're working on it.
I'm not sure about "passionate" programmers, but programmers who enjoy programming are generally always on the lookout for new trends, new tech, new libraries, and even if you aren't using those things, being aware of them is massively useful. If you're relying on the business and your coworkers to drive your skill improvements, then you're going to stagnate, guaranteed, because the business doesn't care at all about new technology and has no desire to improve or change anything, and your coworkers will only care if (shock) they enjoy programming.
When you put together a team of 9 to 5 only in it for the paycheck programmers, what you get is a snapshot, their combined skills and technical knowledge will be the sum total of exactly what all of them know when you hire them and it will never improve. Putting together a team of programmers that enjoy programming and are doing it not just for the paycheck but because they enjoy the craft gets you a constantly improving team. Their skills stay fresh and they're motivated to improve and keep your tech relevant and modern, which ultimately saves you in the long run from having to face massive rewrites of old creaky systems, or ending up stuck trying to hire massively expensive developers to work on ancient deprecated technologies.
Well, vaguely revisionist history aside, that was at least part of what the civil war was over. The southern states were upset that the constitution in the case of slavery could override their state powers and ban slavery. The confederate states wanted to rewrite the constitution to strip the federal government of essentially all powers except the power to wage war and the regulation of interstate commerce, essentially blocking it from having any impact on the activities wholly within a state. The Union states of course wanted to keep the constitution as it was (or even strengthen it), that is giving the federal government veto power over states and the ability to enforce human rights guaranteed by the constitution. Thus in one sense the civil war was a fight over a weak vs. strong federal government. When making that argument though it's important not to downplay the importance of slavery as a motivating factor for the confederate states. Many revisionist white supremacists try to make that argument as a way of whitewashing the confederate states actions and trying to re-frame the confederate states motivations as being non-racist, when they were anything but.
His point is that with the amount of DDoS power available out there to various parties, without a major ISP or CDN hosting your content you can trivially be booted off the internet. Once you accept that as a given, if one of the major ISP or CDN networks won't host your content, then you're open to censorship from anyone who doesn't like your message, which if your controversial enough that the ISPs and CDNs won't host you it's probably a given that someone is going to want to DDoS you out of existence. To further complicate things, most small ISPs when faced with a substantial and prolonged DDoS of one of the clients, will terminate that client in order to preserve service to their other clients, which means once again if you aren't being fronted by a major ISP or CDN will likely mean you'll be hoping from ISP to ISP until eventually nobody will be willing to host your content.
And once again you ignore the elephant in the room. The neo-nazis and white supremacists irrespective of any violent acts are wrong and should be vehemently and regularly denounced as unamerican detestable organizations. BLM has a good mission and purpose. Yes there may be some individuals in the organization that have reacted in inappropriate and violent ways, but the organization as a whole is a positive thing. By not denouncing the neo-nazis and white supremacists in general, and specifically in this case where they resorted to violence, Trump is tacitly approving of them, which shows he is wholly inappropriate to be the president of the United States.
The problem is that his first reaction was to basically say both sides were equally wrong. In this context the two sides where A) neo-nazis and white supremacists, and B) counter protestors who were there to oppose the neo-nazis and white supremacists. This was not a BLM rally, this was an alt-right rally. There might have been some BLM members there, there might even have been some antifa there, but the majority of the crowd that was there was a reaction to the alt-right and in opposition to them, not acting as a member of some other group. By saying both sides were equally to blame he was saying that opposing neo-nazis and white supremacists was wrong. Additionally by not calling out the neo-nazis and white supremacists, and instead merely talking about violence, he's tacitly providing support for them, he's saying that it's only the violent act that was wrong, not the racists or fascists.
Nazis were not socialists, that was optics. The Nazi party actually got into power in a reaction to an attack that was blamed on communists (burning of the reichstag). Whether it was actually communists, or a false flag by the Nazis to seize power is an ongoing debate without enough evidence either way. What is a matter of record is that the very first thing the Nazis did after seizing power was to round up all the communists, and communist sympathizers (or political rivals they could accuse of being communist sympathizers) and arrest them.
Yeah, the congress and senate might actually accomplish something (for good or evil), but the president is just a side show to keep people distracted and drum up ad revenue for news companies (and I use the term loosely).
Sorry, I think there's some confusion about the usage of the word senior there, I meant senior in terms of skill level, not in terms of age. Age shouldn't be a factor at all, it doesn't matter if you're a fresh college graduate or a 60 year old so long as you have the skills to do the job. What you don't want to do is take a highly skilled worker and then hire them into a low skill position, they'll get bored/frustrated, assuming they even accept the position in the first place because presumably you're paying market rates so you'll be massively under paying them in that position.
No, the core of the article was pointing out that setting arbitrary quotas for female hires and then sacrificing your standards in order to meet those quotas does more harm than good. Fundamentally there are two issues that need addressing, firstly trying to get more qualified female applicants which is why she recommends focusing on early education and college STEM programs. Secondly there's the issue of how to address sexism and bias in the industry which results in wage gaps (they're a lot smaller than most of the media makes it out to be, but they do exist), and more importantly in passing women up for promotions or skipping qualified candidates. The later happens rarely thankfully, but it does happen and needs to be addressed, but setting quotas does not fix that problem!
One thing that could potentially help I can think of is encouraging hiring of women in more junior roles (and I mean hiring junior level candidates, not trying to shove a more senior female developer into a lower level position). If we're not seeing qualified female senior level candidates it could be because they're not getting opportunities to learn those skills in lower level positions. I know from experience it can be hard to make room in a team for a junior employee, but it's something that the industry needs to get better at doing if we want people to eventually have the skills to fill those senior levels roles.
Considering all the commentary about how fast/slow the process is, please post an update when it gets approved, it will be very interesting to have another data point to reference.
Reading their process and guidelines I'm guessing that human review is highly variable as well, mostly depending on the size and complexity of the addon. Something massive that's structured poorly is going to take a long time to review since the poor person doing the review needs to actually be able to understand the code. A small addon or one that's structured very cleanly on the other hand should be a fairly fast review.
I'm curious to know what extension you're creating that's so massive it needs a minifier/obfuscator to be run on it so that it's small enough to fit under the file size limits. Also just to clarify, what is the file size you're being requested to be under? Are we talking kilobytes, or megabytes here, because a megabyte of JS is an awful lot of code in a single file.
Taking a look at mozilla's publishing guidelines they're quite clear that you can publish an addon in obfuscated or minified form, but that you need to provide them an unobfuscated/unminified copy of the of the source code to review as well as instructions on how you performed the obfuscation/minification (presumably to run it themselves and compare the output). All of that seems fairly reasonable since you don't want people distributing malware on AMO. One thing I don't see mentioned anywhere in there is a size limit on files though, so I'm very interested to hear what this apparently undocumented requirement is.
There's also a question about if the ads are collecting any tracking info or not. There's a specific exception to the anti-circumvention clause in the DMCA for anything that can be used to collect personally identifiable information. If the ads being shown are of the typical variety then it's perfectly valid to circumvent them per the DMCA.
On the plastics front, just look at the news from earlier this week of Lego working to replace all of the plastics used in their toys with bio-plastics (or other non-oil based polymers). A few more efforts like that and plastics won't be anywhere near the driver of oil consumption they are now. That doesn't address shipping (which is horrendously polluting), but if that's the last one standing that's still a massive improvement.
By way of analogy I'll compare languages to languages, specifically spoken and programming. Going from Java to Kotlin is like going from French to Spanish. Going from Java to Scala, is like going from French to Klingon.
More concretely, Scala actually had very little in common with Java. Yes it ran on the JVM, but that was where the similarities stopped, its functional layer and type system were effectively incompatible with Java or the Java standard library. Actually Scala was so badly made, its functional pieces weren't even really compatible with its own OO pieces, if you tried to mix and match the two it caused all kinds of problems. Kotlin in contrast is almost entirely compatible with Java. There are a couple rough spots, mostly around when frameworks depend very heavily on reflection and bytecode manipulation (particularly around annotations), but those can be worked around from both sides without too much trouble, and the rest of the time it's pretty much completely transparent.
Anecdotally my experience is that for every one really good developer there's about 25 or 30 mediocre ones, and 5 or so really terrible ones. This is based mostly around what I've seen conducting interviews in my area. That is also highly variable, I did some interviews for another office (in another country) and saw ratios more like for every three good developers there were two mediocre ones, and no terrible ones. Maybe we just had a much better recruiter feeding us candidates in the other country, or maybe they just have exceptional programmers living there.
I never considered Scala a better Java. Scala was attempting to be a better language on the JVM, but you'd have to be tripping on something seriously heavy to think Scala even remotely resembles Java. Scala was basically the unholy love child of OCaml, and Haskell, with a tiny sprinkle of Java on top to make it play nicer on the JVM. I had high hopes for Scala, I'm a huge fan of Haskell, but I just couldn't bring myself to like Scala, it's an ugly language that ruins everything good in Haskell by polluting it with OO.
Kotlin on the other hand, really is a better Java. If you take Java, remove all the biggest day to day headaches, change around the defaults to be sane (I.E. the default is what you want 90% of the time, instead of the other way around), and add in some functional inspired helpers, you basically arrive at Kotlin. The delegate system, the way they finally got rid of the need to make pointless getters and setters on the off chance you might some day want them and not want to refactor your entire codebase, making classes and methods public by default since that's what you want almost always, and making types non-nullable by default are all MAJOR improvements over Java, but not something completely alien to the Java way of doing things.
The jump from Java to Kotlin is a lot less than the jump from C to C++. 75% of Kotlin is just syntactic sugar for things you are already familiar with in Java (things like defaulting to public access), so those are really easy to wrap your head around, and the remaining stuff isn't that far removed from what you're used to. Going from C to C++ on the other hand is introducing OO concepts, and then there's the STL which is basically an entire second functional language on top of C++.
I honestly don't understand what the motive for the TSA is. I mean, yes it's security theater and political "we must do something" in action, but it doesn't seem like that's enough to justify the continued stupidly of that organization. The best guess I have at this point is that the combination of a convenient jobs program that isn't republican kryptonite, plus convenient pork projects (hello body scanners), with the added bonus of a perpetual excuse to eliminate personal freedoms and drum up the boogeyman man of terrorism whenever it's convenient is just too tempting to let go.