vault_
This is a feature. I would infinitely prefer 12 PRs that each take 5 minutes to review than 1 PR that takes an hour. Finding a few 5-15 minute chunks of time to make progress on the queue is much easier than finding an uninterrupted hour where it can be my primary focus.
> - The of the feature is split across multiple change sets, increasing cognitive load (coherence is lost)
It increases it a little bit, sure, but it also helps keep things focused. Reviewing, for example, a refactor plus a new feature enabled by that refactor in a single PR typically results in worse reviews of either part. And good tooling also helps. This style of code review needs PRs tied together in some way to keep track of the series. If I'm reading a PR and think "why are they doing it like this" I can always peek a couple PRs ahead and get an answer.
> - You end up doing work on branches of branches, and end up either having to become a rebase ninja or having tons of conflicts as each PR gets merged underneath you
This is a tooling problem. Git and Github are especially bad in this regard. Something like Graphite, Jujutsu, Sapling, git-branchless, or any VCS that supports stacks makes this essentially a non-issue.
This isn't really true, and it's especially not true when specialized hardware comes into play. If you have a "web-scale" GPU workload, it's not unlikely that you'll hit resource availability constraints from time to time. The question isn't whether cloud capacity is larger than your demand for a particular resource, it's whether cloud capacity is larger than the aggregate peak demand for that resource. Cloud providers aren't magic. They engage in capacity planning, sometimes underestimate, and are sometimes unable to actually procure as much hardware as they want to.
The way I see it, circuit breakers are safety devices. They're for when you need to keep a system in a safe control region and are wiling to sacrifice some reliability in order to achieve that. e.g. preventing customers from accidentally turning your globally distributed whatever into a DDOS platform or limiting the blast radius when infrastructure automation decides it should delete everything.
Having recently started participating in a community where most useful discussions are on a PhpBB forum, going back to linear posting was actually refreshing. It's easy to stay on top of because you can check in once a day or so and see just the conversations that have updates since you've last checked them. Threads being sorted by most recently updated means you focus on where there's active discussion. And once you've read those things there's no reason to stick around. "That's it! Get back to doing something useful."
Obviously, this doesn't really scale to a community the size of reddit, but I think it's really pleasant for medium-sized communities.
In my opinion, the physician in this example is a monster. Profit maximization is a choice, not some kind of moral imperative. Am I supposed to have any respect for somebody selling out their employees and patients to vampires so they can retire to a beach or whatever?
The solution I'd want to see for situations like this is to find a way to sell to the people who have a continuing interest in how the business is run: employees and customers. The "exit" that does right by all interested parties would be something like having a newly formed employee coop gradually buy out the founder's ownership stake. To make a tech analogy, you don't have to sell your 0-day to foreign government just because they pay more than the bug bounty program! You don't have to sell out your community to vampires because they're the highest bidders! This is a choice that somebody is making.
Which is to say, using the "right" tool is nice, but not always in the budget. R or Julia may be a better language for data science than Python, but if you're the only one using them, you're just making things harder for the rest of your team. A Python shop has probably invested in coding standards, linters, test infrastructure, common libraries, and has expectations for how code runs "in production". Expect that you'll need to clear at least some of that bar for a new tool you introduce. Expanding towards tools that better fit problems is good, but unless you're doing 100% green field development it needs to be intentional and measured.
First, you can't view product details without paying for a subscription. I wanted to look at the t-shirt to see basic details like sizes available, product measurements, material, and country of origin. I made an account but that still requires paying $70 before I can actually see product details. That's a tough pill to swallow for something I might not want to buy.
Next, there's not a return policy specified anywhere (maybe if you have a membership?). For online clothing stores, I tend to expect that returns are included, but the price-point here would make me more cautious. Does the membership pay for my returns?
Finally, the products themselves seem pretty generic (I realize that's the point). But there's a difference between "we created/are using a generic pattern" and "we are reselling blanks intended for printing. Specifically, why should I buy the latter from you? And if they’re original designs that are made well and from quality materials, what actually goes into that?
Which isn't to say that rewriting can't be cheap, but some intentional design (or at least diligent maintenance and refactoring) must have gone into the system to support that style of development. At which point you're back to targeting "quality," even if it's no longer a focus of on the smaller scale.
With the recent NPM stuff fresh in my mind, it seems like you've got a lot of data serialization libraries as dependencies (YAML, msgpack, rapidjson, marshmallow). Are all of those really needed? Why depend on rapidjson at all when Python has builtin json support? It'd be nice if the default config used only builtin libraries here and allowed users to use something fancier or faster if they wanted to.
It's not spelled out particularly well how subjects actually acquire roles and permissions, or how given a subject I'd go about giving them new permissions.
More integration how-tos in general would help a lot with getting started. e.g. Here's how to make this work in a single sign-on environment. Or here's how to use ldap for authentication. Or (how I would want to use this) here's how to use SSO for authentication, group memberships from LDAP, and permissions those groups have from a database.
Is there any way to deny privileges based on permission/role? e.g. If I have a forum that doesn't allow new users to post until they've been vetted, I'd like to be able to say posting requires the 'user' role, but forbids the 'new user' role. Is there some other way to quarantine users?
You say "Because most account stores usually contain Subject information such as usernames and passwords, a Realm can act as a pluggable authentication module in a PAM configuration". Do you just mean that a realm is similar to a PAM module? Because it sounds like you're saying you can actually stick a Yosai Realm in a PAM config. I can see the similarities between a hypothetical LDAPRealm and pam_ldap.so in terms of authentication, but do realms have analogies in other behaviors of PAM modules?
You describe Yosai as being batteries included, but don't seem to be including many useful batteries (LDAP, OAuth, SAML). I know this is an early release, but do you see these being added to base library?
Yosai_AlchemyStore gives me yet another user model (that claims the user table no less!). Can't I provide it with my own?
This is promising though! Most similar libraries tend to be tied to one specific framework or another, so it would be very nice to have something standalone.
(edited for grammar/coherency/tone)
We have a grid computing environment set up (using Sun Grid Engine) that allows people to run bulk jobs across both dedicated clusters and in spare cycles on lab machines. The way it was set up, CPU jobs on lab machines were set to an extremely low priority, so they don't interrupt legitimate use, and the jobs in some queues were set up so they'd be suspended when real jobs needed to run.
I'd submit hundreds of jobs to the background queue, which would run for a couple of hours and then stop. I also had access to a fairly large number of Nvidia GPUs which were used largely to teach people Cuda and run big simulations every month or so. I was able to use a pretty good portion of my college's compute power without being particularly annoying to other users.
I stopped after a while (maybe 2 weeks), because it was rather inefficient (I mined about 0.04 coins, at the time worth about $8) and because it was a huge pain to maintain. I would probably do it again with a different currency, but it's really not worth it.
I'd be interested to see the demographic breakdown as high school, college, or not in school. I think it would offer more insight into a trend.
[1] This is anecdotal. I'm in college currently and most of the people I know are on family plans.
You get laid off and along comes unconditional basic income. Your $20K is covering your basic expenses pretty well, but you're bored out of your skull (you sold the TV after you were laid off). Rob says he's getting the band back together and after a while you guys think you're starting to sound pretty good.
A year later your boss calls and offers you your job back. He wants to pay your $6K, you negotiate part time for $4K so you still have time to devote to the band. Your boss agrees since he can just hire another person or two for less than your old salary.
With your extra money you pay for time in a recording studio and new instruments. Your band becomes wildly successful and you quit your job since royalties are now making you wealthy beyond your wildest dreams. And so you rise above your entry level beginnings and tell people stories of how you've achieved the American Dream until you die.
There were occasional problems I was given in my high-school calculus class where the goal was to find the area under a curve of a function that was difficult or impossible to integrate by hand. The calculator does it numerically so we were forced to recognize which types of problems could be solved exactly and which could not. Intersections of curves can also easily be solved with a graphing calculator.
Other things like systems of linear equations, probability distributions, statistics, combinatorics, and rapid data entry and processing can also be done really easily on a graphing calculator. These are all tedious to do by hand, and all make an appearance in upper level high-school math classes.
Part of taking a math class should be learning tools to solve your problems efficiently, and exact solutions are often not the most efficient way to do that. Things like Excel, Python, and Maple are all nice but they assume access to a computer and would require significant disruption to lecture flow. With a graphing calculator it's easy for students to do these things themselves (at their desks) without having to give them each a portable computer (which causes other problems with keeping the students attentive) and teach them a programming language.
The author of the article is not condemning people for being self-taught; he's condemning them for being arrogant. I would self-identify as a self-taught know-it-all and understand the behavior he's talking about in the article: pointing out minor inaccuracies in things the professor says, answering every question (to the exclusion of others being able to answer), and asking irrelevant "questions" largely just to demonstrate how much better you are than the other students. It's really not that hard to realize that this behavior is disruptive and avoid it.