mcgwiz

Agreed. I will add that, in the absence of the Executive Branch making such a substantial signal (as opposed to the rhetorical signals in Obama's speech), at least the "fourth branch" has shone a light on the matter. It is a weak light no doubt, and is characteristic of the spineless institution of local broadcast journalism, but the fact that the issue was mentioned at all implies an evolution of the American psyche on this. If Obama, in his heart, believes in "fairness and justice for all", he has no better opportunity to demonstrate it.

Also, I keep thinking about how events like this (e.g. 9/11) engender sympathy and support from other nations. America can build on that goodwill--rather than dishonoring, abusing, or squandering it--and regain a fraction of international moral stature by ensuring Tsarnaev is treated as legally and morally fair as possible. This is a longer term, strategic goal (i.e. politically, socially difficult) that has been undermined and overlooked for too long.

It seems to me there's some disconnect here, as I don't understand how your comment has bearing on mine.

My point was that, given experiences that do not align with prior knowledge, it's no one's responsibility but their own to understand the basis of that misalignment. They can take a shortcut and jump to a conclusion, or they can take a longer, costlier route and seek more information.

The first part of your comment supports me. I'm not sure what exactly about NLP (which I'd never heard of before your comment, and just skimmed on Wikipedia, so I might be missing the cultural context you are referring to) that I should apply the "argument" that one is responsible for his own learning, and that jumping to conclusions (as I characterize the OP to have done, by asserting that the 5 "Agile" projects he worked on must, for some reason, be representative of Agile) will leave you frustrated in the long-term.

I understand there is a social aspect to learning, and that we can all be victims of herd mentality. The question is do we interpret such a situation as one of abuse (where we look for fault), or as one of misunderstanding (where we look for deeper understanding).

It's not about fault. It's about responsibility. It's your responsibility not to expect explanations of observed inconsistencies to be spoon-fed to you, and generally not to expect the process of learning, of improving your understanding of the world, to be necessarily simple, trivial, straightfoward, obvious, or efficient. Otherwise, one almost necessarily (and with great fustration) jumps to conclusions about everything. Occasionally, the assumed conclusion is correct; unfortunately, that reinforces an unrealistic, unsustainable, and unpredictable pattern of learning.

Illogical.

You think because the awful projects you worked on called themselves Agile, that Agile is bad? I hate to break it to you, but you are not special enough for your personal experiences to define "Agile" for the rest of the world.

I learned about Agile, Scrum, XP, Kanban, and project management in general through a self-motivated quest. I didn't accept what I read until it was corroborated. I sought the authoritative texts (original works) and the underlying principles of what I read.

Least of all did I take at face value the claims of the clearly incompetent that happened to be physically in my presence.

This misses the point. Scrum is not merely a prescription of sequential high-level actions.

Fundamentally, scrum is a recognition of certain risk-bearing concerns in projects, and the assignment of those separate concerns to specific roles. The division of concerns sets up a structural tension that drives attention to risks and which are necessarily resolved through open negotiation. To truly reap the benefits of Scrum is to appreciate the value of this tension.

All the steps listed fall from this basic understanding.

Google is betting on Google+ being the future platform for general content publishing and consumption, so RSS in general, and Google Reader in particular, are effectively competitors of Google+. I wouldn't be surprised if Blogger was shutdown (or subsumed by Google+) 5 years from now.

I agree overall, but I don't think the basic mechanism of why we have more work than ever is "jobs finding a way." That characterizes the process as jobs self-replicating, mutating, and adapting.

It's more that improvements in information processing generally (over the long-term) raise all boats, and do not fundamentally alter capitalism's competitive essence. Increasingly complex information processing can be automated, but that just moves the competition to a different playing field (er, boat pond). Until computers can create optimal, marketable solutions to novel problems, competition will always provide jobs for humans. They will just be different jobs.

Harder to test, of course.

That's the hunch I had reading this (as someone with no EmberJS experience).

To digress a little, it's not much different than the terminology confusion in Backbone, where:

- Router(s) work as front controllers,

- templates (along with the browser's DOM) as views, and

- Views as presenters (from the MVP pattern).

Models are flavored with the Active Record pattern. Presenters and views are tightly coupled.

MVC and MVP coexist because the controllers respond to navigational input (mapping to model-presenter pairs) and the presenters respond to page-specific input (mapping to model manipulations and, possibly, server calls).

> It gets a lot sillier when you realize that nobody would title an article "Logic is not for everybody."

> Programming is just logic plus communication.

Fair enough, but you are defending programming as a hobby or academic pursuit. That is not the context established by the original video, which was programming as a profession.

Typically: Professional programming ≈ Logic + Communication + Fat Salary + Bureaucracy/Politics - Predictability - Sufficient Time/Dev Resources - Personal Time

If anything, perhaps some ambiguity can be removed by titling it "Professional programming is not for everybody".

:) DH2, or DH3, at best. http://www.paulgraham.com/disagree.html

Market-driven vendor support of Linux is not unprecedented. Ever heard of Dell, Lenovo, Acer, Nvidia, or the Android ecosystem?

These are always interesting articles, but rarely of practical value. Performance is only one concern of a website project. I've found that a greater risk by far is predictable modularization, a topic with much less "engineering" attention. Any decent-sized project is going to have to decompose their presentation declarations info manageable artifacts, which has the unwanted side-effect of spreading out existing selectors across multiple files. Add to this a tight project timeframe, several engineers that treat CSS as a second-rate language (as almost all that I've encountered do, worsening the more senior they are), and CSS' lack of selector-spacing (in the namespace sense), and you have a recipe for thermonuclear battles over selector specificity.

Selector and naming conventions can basically eliminate this problem. Module root elements have a class name that starts with a letter; module nested elements have a class name that starts with a dash. These are combined with the child selector to constrain their applicability.

What was once super-ambiguous, e.g.

  body { color: black; }
  .menu .item { color: orange; }
  .menu .item .menu { color: black; }
  .menu .item .menu .item { color: orange; }
  /* and on */

is now very precise:

  body { color: black; }
  .menu > .-item { color: orange; }

Is it the most efficiently interpreted ruleset? No, and I don't care. It's the most efficiently manageable ruleset. (Web Components will probably obviate this.)

> Linus is really smart, but sometimes he makes a snap decision and then will perform whatever mental gymnastics are necessary to defend it to the death.

Hmm, could it be argued that this is less a snap judgement and more one of strengthening the long-term political and technical health of the OS? Rather than take the easier short-term path, which may eventually put Linux's metaphorical balls into a Microsoft vice, he would rather expose some pain now to defend as much as possible long-term autonomy. I would imagine this to be true given Torvald's historic ability to keep Linux healthy and viable in spite of one of the world's most powerful corporations.

Thus, in the short term, the user must perform some gymnastics to boot new kernels, but if this inconvenience is really that painful, it will create market disequilibrium that will motivate creative solutions. Some naive, off-the-cuff ideas:

- vendors pre-installing trusted root certs for Linux distros or a consortium of them,

- vendors making it easy to disable SecureBoot (physical switch?),

- vendors forcing SecureBoot configuration/opt-in on very first boot,

- UI, tools, or documentation enhancements to make local key management and signing easier, or

- simply a slightly more aware userbase (the same way phone locking/unlocking became a mainstream concept).

I disagree. No one's asking for a literary masterpiece, just a simple and organized explanation of what we're looking at. I would argue that the value is more in the process of creating this simple explanation, because it forces you to empathetically examine the code from a a foreign mindset, and from there to re-order and organize the code in a way that's amenable to conversational (simple) explanation.

This explanation may include requirements and other concerns, description of alternatives and why they were rejected, references to other parts of the codebase, and its high-level design intention (i.e. vision) in order to guide the direction of refactorings and extensions.

None of this requires analogy, symbolism, foreshadowing, subtlety of tone, or even a mastery of diction and syntax. Anything resembling Yeats or Dostoyevsky is counter-productive.

Credit for owning the scope of the problem (allowing serious discrepancies for 3 years), which is sure to cost them trust from the community. But the skeptic in me reminds me that it's likely there was no way out of admitting it.

What disheartens me is that the documentation discrepancy caused real, extremely substantial aggregate monetary impact on customers, yet there is no mention of refunds. Perhaps that will come, but in my opinion, anything short of that is just damage control.

This is a time excessively demonstrate integrity, for them to go above and beyond. It's in their interest not to just paper over the whole thing.

(General response to a trend in the comments.) I believe #2 refers to things like Wordpress.com or CloudFoundry.com. Wikipedia.org might qualify as well. If Discourse.org offers hosted instances, (and they make a lot of revenue), they could qualify too.

As far as I know, GitHub never opened their source.

Before we let the pendulum swing from one cargo cult to another, let's simply recognize that there are often more cues involved in conveying an interface's intention.

A login form will be accompanied by a Login button, for example. In this case, the intention of the two preceeding input fields should be obvious. (A well-designed site would permit any unique user key, including email and username.) Placeholders, in this case, are generally acceptable.

At the other extreme, a customer information form would have to rely more heavily on explicit, rather than inferred/implicit cues. This includes labels, and their heavyweight siblings, descriptive tool-tips and sidebars. Very complex forms may require extensive documentation.

Most problems have a whole spectrum of possible solutions, supported by a wide variety of tools. Don't let a single aggressive voice narrow your understanding of that.

Looks great!

I'd just like to note that those working on Backbone single-page apps hosted by an ASP.NET site can also achieve this idiomatically, with the use of the Nustache view engine and controller actions that can do HTTP content negotiation.

Yeah, I concede mine wasn't pixel-perfect.

To continue down this path of the "natural" way to vertically-center, font-size must also be explicitly set. This works http://jsfiddle.net/nJy8t/3/ . Though it's certainly not without it's flaws (we lose font-size cascading).

You're right, I had a bug: http://jsfiddle.net/aMMxj/51/

Idiomatic solutions, by definition, cut out the non-semantic document structure. Certainly you will find layouts that cannot be achieved idiomatically in CSS, just as certain software patterns are more idiomatic in one OO language than another (e.g. observer pattern in C# vs Java). But the more scenarios you attempt to address with the language, the more complex it becomes. It's quite possible that extensions to CSS would open it further to the criticism that it's too complex.

Unfortunately, browser vendors do not support any other stylesheet language. Perhaps if this were different, there would be more effort to understand stylesheets from an engineering perspective. Since it's not, we're stuck with poorly-thought conventions and a community that's been trained to despise the language.

CSS is not a happy language, that much I'll agree with. But I find it no more painful than other computer languages. I reassert the lack of rigorous analysis by CSS users and the collective community as the main solvable problem. I have worked at extremely pricey consultancies, and the only thing I learned about CSS from them is that the more senior of a developer you are, the less respect you have toward CSS as an engineerable technology.

1. Not true. Could have been an image, or even SVG element http://jsfiddle.net/aMMxj/55/

2. Fair enough. It would be nice to be able to set line-height to a percentage of height.

3. Bug, my bad. http://jsfiddle.net/aMMxj/51/

There may or may not be Great CSS books out there, but in 10 years, I never found any. They invariably teach you recipes, but not how to to think in the terms the language was designed.

The ruby community is one of the most active and rigorously analyzed in contemporary programming. Blog articles are well vetted, and Google search can reliably point you to decent articles. Further, ruby belongs to a class of languages (interpreted, general purpose, imperative/OO) that is very well understood. Languages from this broader ecosystem include python, perl and even JavaScript, all contributing to a deeper analysis of each.

CSS is a stylesheet system. There are no other popular systems in use. The comparison could be made to Microsoft Word's style system (which has a very different conceptual model). Such a comparison could yield interesting ideas. But such a comparison is never made. Other stylesheet languages for structured documents include the unknown FOSI and DSSSL. When was the last time anyone cited those referenced in a blog post, tutorial, or book about CSS?

I'm not saying the specs are a good teaching device either. But teaching and precise description are different ends. Regardless, because there doesn't exist a good community (incl blogs, books, personalities) to fall back on, the specs are your best bet. Ultimately, they (along with other implementations) are what inform browser implementations.

Let's clarify the question.

"Does anyone have any insight as to why vertical centering of dynamic-height content is the way it is?"

Yes. The original standards committee created a layout model (block, inline, and inline-block elements) that (they felt) adequately balanced language complexity with features. It's easy to idiomatically achieve vertical centering. http://jsfiddle.net/aMMxj/10/

"Does anyone have any insight as to why people that code CSS complain about it so much?"

This is a much deeper question, but one that I think is far more informative. Having done front-end engineering for 10 years, across industries, and in very pricey and exclusive consultancies, I have never found another engineer who had read the bulk of the CSS spec, or even a book about it, for that matter.

Developers, the ones with the mind and experience to bring technical discipline to CSS and create a set of idiomatic patterns (both low-level and high-level), treat CSS as a second-rate citizen. The bulk of the rest of the CSS userbase consists of visual design types (coming from print or graphic design), where the tools of the trade are physical pen and paper, or something from Adobe Creative Suite. The remaining portion of the userbase are equally non-technical hobbyists.

This is the real problem of CSS. Those that have the mindset to devise idiomatic conventions to the community don't think the language is worth it. At best, you have semi-experienced developers duct-taping various non-idiomatic ideas together and giving it a fancy name.

These products exploit/capitalize on computer illiteracy. That's not something I would personally be proud of, but computer illiteracy is the real problem here. Products like this can ultimately accelerate the correction of computer illiteracy.

That correction can come in the form of greater mainstream cultural impetus for computer literacy training, for operating system developerrs to prevent these types of actions (app stores of all platforms are decent at this), or by creating/expanding a market for products that intercept and neutralize this type of exploitation.

The more efficient the means of exploiting computer illiteracy, the sooner the exploit is, in some way, neutralized.

Pardon my pedantry, but CQRS doesn't necessitate eventual consistency. Denormalization of domain events into can happen synchronously. It all depends on the needs of the project. If the project information architecture and processes can support a degree of latency (which is implicit in almost any technology providing static screens anyway), then the performance gains of eventual consistency can be realized.

A good, nuanced explanation of CQRS is here: http://codeofrob.com/entries/cqrs-is-too-complicated.html

You're certainly entitled to your personal opinion, but really? You're saying that it reflects poorly on someone to relay a story of poor treatment toward them? You don't find any value in knowing this? Have the experiences of others never influenced your own decisions?

The author let the other party's tweets speak for themselves. There was no unnecessary or subjective sensationalization. Personally, I found this an informative (and weighty) data point.

India is a huge country, and I would assume that cultural norms vary throughout. In my view, the heart of the issue is a lack of attention to the problem by those with power, creating an environment with no consequences for this type of behavior. Self-defense can both attract attention and effect consequences (both directly and indirectly through the attention brought).

Generally speaking, cultural norms rarely change overnight or through some collective and conscious agreement or referendum. Among other things, the combined effect of individual actions can spark cultural change.

I don't know if the link is legit or the most efficient organization to do this, but pepper spray can certainly be a single vector among many to effect wider change.

Agreed. Users care more about getting the task done then having an emotional relationship with the system. To inject sympathy into what need only be informative/instructive, is to call attention to the user's ignorance in fabricating false expectations of the system. That's more offensive than anything else.

Only in the case of the system inadvertently failing to meet the expectations it made (e.g. database server inaccessible) would apologetic messaging be considered.

I agree. I know I've certainly been offended by inanimate or even virtual objects. Closed source libraries with bugs or convoluted APIs are some of the most offensive things I've ever encountered.

But either the system was buggy (or the product was faulty or cheaply made, like a hammer that breaks on its first use), or the user simply used it incorrectly. Both can be phrased in terms of expectations. In the first, the developers failed to meet the expectations of the system (either explicitly set through marketing or usage manuals, or implicitly through interface design). In the second, the user ignored design cues and fabricated incorrect expectations, which the system then did not meet. I will say only the first case deserves apologetic tone, while most replies to the link are arguing that the second case deserves apologetic tone.

Why a system is responsible, or should show sympathy, for a user's ignorance of design cues is beyond me. I argue that most users prefer to only get the task done, and care more about whether the error messaging includes corrective advice than any apology. In fact, injecting apologetic, sympathetic emotion into an objective transaction only seeks to call attention to the user's ignorance and errant fabrication of expectations. Now that's offensive.

No.

Providing options, with a professional and courteous tone, to rectify the situation is different than apologizing. Polite expressions of options are necessary.

But apologizing? As in, "expressing sympathy"? IMO, no.

Humans do not get offended when their car doesn't start because it's out of gas and doesn't offer an apology. They still love their car, they will still continue to use it.

Humans do not get offended when they click to a cable channel that they aren't subscribed for and an expression of sympathy isn't displayed. They will continue watching television and subscribing to cable.

Humans do not get offended when the hold a hammer by the "business end" and try to drive a nail in with the handle, and an "I'm sowwy!" flag doesn't pop out of it. They will go on to learn the correct way to use it.

Computers are merely another inanimate object. Ultimately it's a system that serves the user when used correctly. A bank teller on the other hand, should apologize because there is the appearance of discretion in the bank teller's undesired response. Applications have no discretion in their actions. Humans are fine accepting that their actions led to an undesirable outcome, especially when avenues of correction are explained. Constant expressions of sympathy are annoying at best, and at worst can plant the seed of mistrust in the design and value of the system.

This doesn't hold when it's reasonable to hold the developers at fault for the undesired outcome. For example, if a feature was removed or redesigned without fair notice, an apology might be appropriate. In this case, they're failing to meet a certain expectation that had previously been set.

Update:

Upon further reflection, I recognize why I feel so strongly about this. I've worked on many public-facing applications before, from finance to social media. In each case, the use of apologetic or sympathetic expressions matched the site designer's personal belief in the value of the system and the correctness of the design. Where they had also expressed doubts about the success of the project, apologetic error messages were standard. Where they believed the project was well-designed and, if used correctly, would benefit the end-user, merely professional messages were used.

I now find myself inadvertently inferring such levels of confidence from all application messaging/copywriting.