I highly recommend reading "The Do's and Don'ts of Client Authentication on the Web" [1] from MIT. It's rather old and not very well-known, but it's excellent. The concepts provide very useful background info that will serve you well no matter what technology you use to implement your HTTP services, including issues like session hijacking, etc. One of it's best recommendations: avoid roll-your-own solutions. Secondly, I recommend checking out the "auth" example from the expressjs repository on github [2]. It will provide a practical implementation example. Lastly, if you're considering using Express or any similar framework, I recommend checking out "route parameter preconditions". These seem to remain a little-known feature of Express, but they can be particularly useful for applying middleware to entire sets of routes, for example enforcing authentication on anything under a certain path. You can still find screen-casts for route-specific middleware and route parameter preconditions on the Express 2.x documentation site by TJ, the original author [3]. Some of the specific details may have changed in the newer versions of Express, but TJ's explanation of the concepts is simple and clear.
It's easy to see graphs trending down and say, oh, interest is waning. But the initial spike could just be lots people going through a learning curve. It tells you something about popularity, but ease-of-use, quality of docs, etc. must all factor in as well. I tend to see the high number of questions on certain frameworks as a red flag.
Mineral oil is also used medically as a laxative; you put a few spoonfuls in a glass of juice and drink it. So, pretty safe to use as a wood conditioner but its not a drying oil so needs to be re-applied from time to time. It's used a lot on wood cutting boards, which take a lot of abuse and need regular re-application of a flowing finish that won't build up in hard layers.
Wax can be used over most wood finishes to to give it added lustre but also needs to be re-applied to maintain it.
The advantage of a drying oil is that it gets absorbed deeply into the pores of the wood grain and dries to a plastic-like hardness. Because the unpolymerized oil penetrates so deeply, the cured finish isn't just a hard layer weakly bonded to the wood surface which can flake off, but weaves itself into the grain and pores of the wood itself. It seems that most people who avoid linseed oil finish complain they don't like the smell when working with it.
Walnut oil can be dangerous for anyone who has peanut allergies, which might be one reason why its not so common.
Nice to see someone explaining drying oils, a discussion usually buried in woodworking forums. That said, in addition to flaxseed oil there a few other drying oils that can be food safe, depending on the additives, like safflower oil, walnut oil, soybean oil and tung oil. In their raw forms those oils are edible, but if they contain a metallic dryer catalyst to accelerate the drying, they're not food safe. I've purchased raw linseed (aka flaxseed) oil in a hardware store in fairly large quanity, labelled as being "safe for farm animals". On the other hand the "boiled linseed oil" sold in the same store contains the chemical dryer and has a label indicating it's toxic. The boiled variety is better as a wood finish when you don't care about it being food grade because it dries much, much faster. For wooden bowls, etc. the raw linseed oil is preferable as a food-safe finish but it takes a very long time (weeks) to dry unless aided by heat / sun.
That, plus attention to detail is just part of the Japanese culture. There's a higher density, very little wasted space, and a slightly smaller scale of the built environment there that always strikes me as having a "storybook" feel, for lack of better words. Manga and anime communicate it quite well visually.
[edit] Not directly related but I find it encouraging that the number of houses and carports there with solar panels on the roof is remarkably high and seems to be increasing all the time.
This argument is trotted out every time the gun violence issue comes up, but there's no veracity to it. The data is freely available. It's been several years since I did this but I plotted gun ownership vs gun deaths per 100k population, by US state, from publicly available databases, and they correlate exactly. More guns = more gun deaths, full stop. It's not a matter of the data not being there to show this, it's more a matter of a really strong cognitive bias that prevents people from being willing to even consider the evidence that doesn't support their preconceptions.
Sorry to hear about your frustration. A lot of people can sympathize, but I can assure you that nightmare codebases can happen in statically typed, object-oriented languages just as easily as they can in dynamically typed, functional languages. Not sure if there's one best way to prevent it. Applying the 'unix philosophy' for better modularity can help; structuring a JS codebase from composable modules is an example. Nowadays I try to approach code with the mindset of "what if we wanted to turn this into a standalone, open-source npm package." Even simple things like writing consistently good README's in every repository can help. If you haven't yet, unit tests and linting should be part of your build pipeline, too.
Not really. It's not that other debuggers didn't provide some of those features and were very good at, say, stepping through program logic. I've spent many years using other debugging tools for C/C++ and Java, and although there are some good IDE's out there, firebug's capability to analyze everything from logic to object models to network activity and visual presentation details, in such a well-integrated and user-friendly way was frankly unprecedented.
Firebug didn't just raise the bar for web debugging, it pretty much raised the bar for all debugging tools. It leaves a great legacy with the built-in dev tools. Great project.
As a pianist, latency of 20ms makes an electronic keyboard instrument unplayable for me. I wasted lots of time messing around with different drivers for soft synths trying to get below that number. 100 ms is a lot. In audio, a 8ms delay has an effect you can clearly hear, and can be used to "widen" tracks or simulate stereo from mono sound sources, since 8ms corresponds roughly to the amount of time it takes a sound wave to travel from one side or your head to the other.
Very true, and we've seen better performance from multi-process than multi-threading in some high-traffic (10Gbps) systems (those were C++ however, not node). It was puzzling, but I put it down to the OS scheduler; I imagine that a single multi-threaded process would be pre-empted in the typical fashion, but that multiple single-threaded processes would, in aggregate, spend less time in a pre-empted state.
Also many providers charge by CPU usage, so it behooves customers to spec machines as lightly as possible and fall back on auto-scaling to spin up additional, equally lightly-spec'd VMs, on demand. Rarely are there many idle cores just sitting around.
Though the functions are serverless in the sense that you needn't allocate virtual infrastructure, the platform obviously utilizes CPU resources to execute your function. That platform underlying the serverless function is, as it happens, multi-core in GCE.
Time limits on serverless functions are 9 minutes on GCE and even less on AWS, so for long-running stateful tasks they're probably not suitable, unless you can divide the work into serial as well as parallel subsets.
This looks great, but it's important to bear in mind the architecture you intend to run on. I recently made an application blazingly fast by - among other things - parallelization using the node cluster module. On my 4-core laptop it flies. Imagine my surprise when I deployed to the cloud environment and found the typical virtual server in our cluster has only a single CPU core. The worker threads just sit around waiting for their turn to run, one at a time. On the other hand, the platform for serverless functions has 8 cores. At a minumum, before you jump into multi-threading, know what `require('os').cpus()` tells you on your target platform.
Some of the comments seem a little disjointed from the details. According to the article, only information that's publicly available online is collected, and specifically for those immigrating to the US, not tourists, conference attendees, etc. There are likely a lot of reasons for many people not to want to travel to the US, but this would probably be low on the list.
I think it started as an affordable alternative to stick frame construction in a few instances where the containers were readily available, but I agree it's become something people want to do even when its not cost efficient in their area. On the other hand, why shouldn't building a house be as simple as joining two or three prefabricated, easily transported, container-sized modules together? It just needs the right price point.
[edit] There's a company called Bone Structure that has a modular steel building system that's almost a hybrid between pre-fab and on-site custom. Still expensive though.
It's sad that in an academic workplace you'd be better of as a janitor than a prof. The facilities workers where I studied were unionized and seemed to manage alright. The abuse of part-time positions is such a scam.
Nice. It's too bad they didn't support that initially. It was issue #3 on their repo, incidentally. I might still be using it if it had been implemented sooner.
Alright, costs. I think it's not well advised to use a type system as reason not to write unit tests. It seems to be a common misconception that static types are a replacement for testing. I think the real question is can you afford not to write unit tests that exercise functions with invalid arguments. I think it's still worthwhile because, like I said, you can have code where all the type constraints are satisfied but become violated by ingested data. You probably shouldn't assume that every user of your code is going to use thrift or graphql or whatever.
I think it's a stretch to say a static analyzer is "a type system". It doesn't obviate runtime type checking and implicit type conversion. But yes, absolutely you should run it on every build.
I feel there should be a counter-article along the lines of "Unit testing and static code analysis conservatively prevent 80% of the bugs". I've used both Flow and Typescript and imho they're both frequently more trouble than they're worth. They catch the simplest of newbie bugs that are rare in modular, linted, unit-tested codebases. There are static code analyzers (eg. tern.js) that provide hinting without requiring a transpiler. With Flow and Typescript you have transpiler overhead, but when it comes to places you might need them the most - checking and sanitizing data interchange that's so common in modular, service-oriented architecture - they fall flat. Flow or Typescript could have been more useful if the annotations truly were annotations in the form of comments, unfortunately they went the transpiler way.
I'm afraid this is what happens when the exercise of democratic freedoms is cordoned within the platforms of corporations who have no duty to uphold them. Google's unilateral suspension of AdSense accounts without reason or recourse has brought this realization to lots of people on a less overt level.
For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.
I started thinking of FB more as a channel to publish notifications of content I keep on other sites, like blog entries, Flickr photos, etc. Once I started thinking of it as more of a pub/sub layer for the content I manage externally, I felt better about staying on it.
I like it, but it could use some refinement. Already a couple of years ago Dave Thomas, one of the original authors of the Agile Manifesto, wrote a piece called "Time to Kill Agile" (renamed "Agile is Dead")[1]. The "lean startup" methodology and guidelines found in "Rework" and "Getting Real" have gotten traction in some of the younger companies in my area but I don't think they've been codified into a single set of guiding principles that could work well for larger enterprises. It might've been nice if Dave Thomas had proposed an additional point or two on the original Agile Manifesto to correct some of the problems he mentions. But it's hard to turn the Titanic around and it seems like "correctives" to belief systems generally come in the form of a competing system that asks you to discard the previous one.