2,303 karma · joined October 13, 2010
If the business ran into legal trouble and had to use up the 40 hours, it wouldn't automatically result in the attorney cutting off services. Most likely, if the attorney thought the business was solvent, s/he would continue working, and would invoice the business for anything above the $10,000.
For me, a static site generator is the bare minimum.
Are you sure? How complex do you mean? How complex do you presume the parent commenter's apps to be? Could you give an example of one of those more complex apps? I'm wondering if I'm currently building apps of the "simple" or "complex" variety, according to your terminology.
I don't think the architecture skeptics claim as much. I believe you're restating the claim in a more extreme way that it's commonly expressed, thus making it clearly indefensible.
The claim isn't that certain architecture patterns have no place in the world. Rather, the claim is that those patterns aren't a good fit for most Rails apps.
Pretty much any pattern (that's not a commonly-accepted antipattern) has some good use case, somewhere.
In principle, the current Rails architecture can support that. Rails permits the test environment to use a different database adapter. There's nothing stopping anyone from decoupling the database at that level. I.e. you can pick a super-fast persistence strategy for the test database adapter, if you so choose. If there isn't an adapter you find fast enough, you can even create one. (Such a project would not doubt be well-received.)
Anyway, for my part, I prefer to run my tests against the same kind of DB I use in production. It gives me greater assurances. Especially when a web app can sometimes depend on the peculiarities of a certain persistence layer. E.g., your app has a search engine that runs custom SQL--you really want to test that against the DB.
Would it be nice to run some of my tests without the DB? Absolutely. Some tests just don't need to test anything DB-related. My guess is that Rails' support for that use case will grow organically over time.
I wouldn't say that always happens. It often happens when a 500-word blog post suggests effectively re-architecting a mature, successful framework like Rails. Let's think about why such a post is problematic.
Rails has evolved over quite a few years in response to actual needs on the ground. Tremendous amounts of ink have been spilled, and tremendous amounts of brainpower have been expended to create a mature framework like Rails (or similar frameworks).
Despite the battle-tested history of the framework, so many of these architecture blog posts imply that Rails' architecture is somehow insufficient. And then propose to fix that architecture, spending, say, 500 words explaining the idea. There's hardly any discussion of the idea's wide-ranging implications, of the trade-offs, or of the conveniences that are lost. If this idea is so good, why hasn't it ever found its way into Rails, even in diluted form? Why has the Rails team built the architecture they have, instead of yours? (Hint: They probably have a good reason.) Do you have strong evidence that your proposed architecture will serve me better than the one that I've been using successfully for years?
All that being said, I have no problem with idiosyncratic Rails techniques that only step a little outside what the framework provides. For example, service objects. Used appropriately (which usually means sparingly), they can help with organization without fundamentally warping the Rails app. Using a few service objects is a departure similar in magnitude to writing your JS in TypeScript instead of CoffeeScript. It's not built into Rails, but it doesn't really change any of the core concepts either.
It wouldn't force an ISP take any action. Each ISP would only be forced to decide how much bandwidth to offer each consumer, and at what price point. If a particular ISP did not feel it wise to upgrade its infrastructure simply because Netflix increased its streaming rate, that ISP would be free not to make the investment.
So how do you deal with network congestion in that scenario? ISPs can continue to offer different pricing plans with different download rates. They can be transparent about the real download speeds for each plan. Perhaps they can even offer a speed estimator tool where the user picks a geographic endpoint and a time of day.
That solves part of the problem of congestion, in that consumer are (roughly) paying for the bandwidth they use. (Theoretically, the users' fees would be scaled to account for the cost of infrastructure upgrades.) But I'd still like to be able to quickly download, say, an API reference page from rubydoc.org without having my connection starved by torrents and video streaming. To that end, perhaps ISPs could grant each consumer a certain GB/month quota of "guaranteed max speed." I.e. until you exceed your quota of X GB per month, your traffic never falls below Y MB/sec, regardless of current network congestion. If you wanted to get really slick, you could even let customers opt certain traffic types out of that program. So I could say, for example, "use my max speed quota for regular HTTP, SSL, etc. usage, but never use it for video."
Ideally, each consumer would have several ISPs to choose from. In that case, the market could discover the optimal plan selections.
Education is clearly one factor, but there are many others. The most effective way to ameliorate poverty is to improve all factors simultaneously. E.g. employment/income, housing, healthcare, incarceration, transportation, education--just to name a few of many factors.
I think that's fine, because as you said, it encourages GPU vendors to innovate. Plus, it probably affords more of an opportunity to squeeze every last drop of performance out of each card.
On the other hand, I'd start to get upset if we had to write card-specific code just to do the absolute basics. (Which isn't the case right now.) There are tons of apps that need only a tiny fraction of the performance a GPU offers. For those apps, it would be insane having to maintain multiple codebases just to, say, draw a box with a texture and Lambert reflectance.
For example, when nothing renders, I don't want to waste an hour, staring at my code with no direction, until I realize I forgot a call to glEnableVertexAttribArray. Instead, I'd like to boot up my trusty debugger and go through a sane process of narrowing down the problem, like I do for just about every other class of bug.
Also a sane way to debug shaders would be fantastic. The usual advice is to write debug info out as color values. The fact that anyone considers that a healthy debugging strategy just illustrates how far behind graphics programming is in terms of developer friendliness.
I don't know if it's better on other APIs. OpenGL is the only one I use, because I never have occasion to develop Windows-only apps.
To make an analogy, C is hard to read for newcomers. But has anyone designed a simpler, better language for describing direct, low-level manipulation of memory? Is it even possible to describe such operations in a simpler way than in C?
That being said, any given patent isn't necessarily written well. Within the confines of the "patent programming language," one can write well or poorly. So I'm not claiming that individual patents can't be edited for clarity. Rather, I'm claiming that the fundamental way patents are written--which is admittedly intimidating--may not admit of much simplification.
To revisit the above analogy, one can write bad C. One can even write deliberately obfuscated C.
You could probably roll your own. A decent middleground would be to keep the data in the central repo encrypted, but keep it decrypted on the engineers' workstations. Though a better approach is just to not check in sensitive values at all.
For more day-to-day stuff, environment variables on the server are an option. If you want to be able to provision a new server 100% automatically and keep the credentials out of source control, you have a few options. You can add a quick interactive phase to the deploy script, wherein the engineer must enter the key manually. Or the engineer could enter a value which is then passed to a KDF.
I agree that a good code of ethics could be that way. But I think that's less true if the code of ethics is coupled with a system of punishment. In a system where violations are punished, I think it's desirable for the rules to be as objective as possible. Otherwise, you risk arbitrary application and/or abuse of the rules. Further, well-meaning people should be able to read the rules, understand what is and is not permitted, and tailor their behavior accordingly. They should not have to worry that they will later be punished for breaking a rule they thought they were following.
With the imperative approach, you make liberal use of the IO monad. There's a lot of explicit reading from and writing to mutable storage. If you're doing this approach right, you mostly just use the IO monad for actual IO and threading; most of the real logic of the program is kept pure. This approach has the advantage of being familiar. And more importantly, it just plain works. It's how I tend to do things.
Yet I can't help but wonder if there's a better way. The above approach, while comfortable, leaves me with a bad taste in my mouth, like I'm somehow fighting against the language. I've often heard functional reactive programming (FRP) described as the best alternative. Though I remain skeptical. I'd be interested in opinions about the future of FRP.
I absolutely want to switch and will as soon as an alternative is available. In my entire life, I've never lived in a place that had anything other than Comcast. And I've always lived in relatively dense areas.
https://github.com/ekmett/lens#lens-lenses-folds-and-travers...
Phrased that broadly, it would be terribly abusive and detrimental to free speech. But imagine a much more narrow rule, concerning only the mass recording and retention of geotagged, timestamped license plate photos. It may be only a quantitative difference and not a qualitative one. But public policy often hinges on distinctions of that sort, as we try to balance competing societal interests.
As to my original question, I'm still curious how you'd feel. What if it were facial recognition on public sidewalks and parks, and not license plates? Would you feel differently?
Wherein the programmer plays the role of social worker. Seriously though, the skill sets are very similar. The client is typically the ultimate source of the requirements, but it's never a simple case of asking the client "what should I build? More often than not, the client doesn't know what s/he wants, wants something that will actually hurt him/her, is actually seven different people who want opposite things, wants the roses simultaneously painted white and red, etc. Which is why I find requirements collection the most challenging part of the job.
Any language can be written poorly. I don't think any language will ever be able to force good coding style on programmers. Though Haskell comes closer to that impossible goal than many other languages, due to its type system, functional purity, and mandatory indentation.