mikaraento

I think the parent meant Jubal Hershaw, who does rather read like Heinlein's dream image of himself.

Many people call this "Enterprise architecture" and although painful tends to be worth doing.

You can think of it (simplified) as 4 steps: 1) figuring out and deciding which technologies to use for which domains and problems (these tend to be called capabilities) 2) getting rid of the ones you don't want to use 3a) enforcing use of existing, approved capabilities for new projects 3b) building out new capabilities

1) Tends to have the problem you pointed out: "it requires a greater level of technical depth in decision makers". Something that may work is to have some senior engineers in-house and embed them in the outsourced projects doing part of the real work. 2) This can be a multi-year program that needs to be separately funded. Think of it as enterprise-level technical debt. 3a) This can be the easiest part: your architecture should be part of the RFP process, with a well-defined escape hatch to 3b) 3b) Building out new capabilities needs to be i) funded separately but best ii) done as part of a real project. Otherwise you'll i) have crossed incentives with the projects as you pointed out, or ii) architecture astronauts.

HTH. There's plenty of literature on enterprise architecture, but there's no silver bullet, it's just hard work.

Until five years ago the consensus view was that moderate alcohol consumption lowered all-cause mortality compared to non-drinkers.

Latest meta-analyses say that after controlling for reasons behind non-drinkers (‘former alcoholics’) the effect disappears.

Good starting point is https://www.ncbi.nlm.nih.gov/m/pubmed/26997174/

Do note that an SMB exploit does give you privilege escalation once inside a network.

Previous discussions https://news.ycombinator.com/item?id=8275970 and https://news.ycombinator.com/item?id=12300953

(not because I want to dismiss conversation here - did want to read up on it myself)

I don't completely agree. While git definitely could still be more polished, the problem it tries to solve is fundamentally complicated.

Git does a good job of cleanly modeling the graph of distributed changes and providing a set of useful operations on that graph. The disagreement is more about whether somebody has learned or should learn that underlying graph.

I think the uphill's not too steep - keeping track of the aliases on your own is quite reasonable.

The thing that does _not_ work is not using namespaces to decide on the meaning of tags/attributes when processing XMPP :)

I've found improving style checks file-by-file to be a reasonable approach:

- all new files are checked

- old files are put in a whitelist for the style checker, the submitter is supposed to remove the file from the whitelist when signifcant changes are made

Please consider chipping in at StackExchange to help find out an answer to this. There have been a number of discussions on about how to handle obsolete answers without a clear winning idea or feature - it's a difficult topic.

It looks like a weekend project but isn't. Scaling it up took Twitter a long time. Showing your feed is a very expensive operation (there are users with a large number of followers and users who follow many others) and syndication and clients amplify the number of operations.

Source: I was one of the developers of Jaiku, which had a very similar model.

Having a political view or religious belief is almost synonymous with acting on that - participating in the political process or your religious community. (Though you shouldn't be doing these at work).

To be uncharitable, you are taking an unreasonably narrow view because you disagree with Eich (I do too), but like with freedom of speech it's all about the case when you do disagree.

The term has a specific meaning in the context: letting the user drive the order of interaction instead of following a set sequence. Many early character based interfaces forced the user follow a specific process (think filling in a form field-by-field). We are now taking the paint/word processor/window manager interaction where we can click on anything we want any time for granted.

Also: writing good macros is (even) more diffcult than writing good functions or modules.

Writing macros is doing language design and compiler implementation at the same time.

If you've ever cursed the error messages from a C++ compiler, think how much worse it would be if that compiler was written by your co-worker part-time as a side effect of writing rest of the code.

(I wrote clojure in anger for three years with brilliant co-workers)

The DOM _is_ only rendered after your JavaScript is finished running - as long as you don't ask for properties that can only be known By rendering it out.

Perl, Visual Basic 6 and to some extent Python are examples of languages using the moral equivalent of ARC.

It is somewhat correct to say that it's an evolution of the internal platform, as in that it indeeed used the same mechanisms to spawn jobs; but in the way it provides a PaaS it was very much a parallel track - instead of naming and allocating the different backend instances you just get all of them in a box.

This matches my experience: Docker is very promising, and indeed already a very good solution to development and test environments - but the productization level is still low. You need to invest a significant chunk of time to get things actually working.

Most templating languages have binding syntax, and most people want them to have some.

That said, I too find the documentation too brief, especially on things like ng-repeat's filters.

A good touch UI is not a good pointer-based UI and vice versa.

A touch UI needs large hit zones, benefits from natural drag/scroll, has only one kind of click but can have multiple touchpoints.

A pointer UI can use very compact and precise interaction areas (text selection is a great example), right- and option-clicks and has very old conventions for drag and scroll.

Saying that Windows is touch unfriendly is missing the point of it being very pointer friendly.

Apple is slowly bringing the two paradigms closer, and people complain at each step.

I think the biggest reason health insurance is provided by the employer, rather than bought by individuals is adverse selection.

Simplistically: people who are more likely to suffer an illness (e.g., people with pre-existing conditions) will buy more insurance, and people who think they'll be healthy (e.g., younger people) will buy less. This drives up the amount of payments per insured, which drives up price, which further drives healthy people not to insure.

That's why you want health insurance purchase to be independent of risk of illness, which is (at least somewhat) what the employer-provided insurance does.

This is probably also the main reason state-provided health insurance might be a good idea.

Banerjee's and Duflo's 'Poor Economics' gives you a more detailed and nuanced explanation pp. 147-151. Great reading throughout.

XMPP's federation is great, but it's a real pitas to scale up a single domain (long-lived connections, implementations typically assuming one node, dialbacks). The gtalk team had a really hard time with it. Http is a lot easier to scale.

Well that was interesting.

The cost is indeed in the paint (the lagging top-left quadrant redraws the whole map svg).

The difference in the tl and other quadrants is that the other quadrants were causing a synchronous layout because they were asking for the highlight's size to position the tooltip. And this was _faster_, because the different sequencing of layout and paint resulted in a less expensive (partial) paint.

BTW, if you actually want to make this kind of tooltips for complex SVG I recommend having the continuously updated part to be in its own HTML element with styling to make it hardware-accelerated ('div style="-webkit-transform: translate3d(...)'). That way only the changed parts are repainted and the compositing is done by the GPU.

(Well, actually modern IEs are very good at optimizing the SVG changes, but Webkit isn't).

Although I roughly agree with the sentiment ('if you think everybody else is leaving money at the table, you should be picking it up rather than complaining about it') - there is evidence to the contrary.

A large part of the post-WWII economic growth of the Soviet Union has been attributed to the integration of women into the labour force - and the final stagnation to the fact that at that point there were no more women to integrate, everybody was already working.

I think it's a good fit on mobile.

The mobile browser performance is still much lower than on the desktop, so you don't want to render too large a DOM at once.

Loading a new page over the network can easily take 10s, if you need to reactivate the 3G connection from a low-power state. Of course you can use a single-page-app approach to help that bit.

Scrolling in one direction is one of the easiest (and most fun) interactions you can do on a touch screen - clicking is much harder.

That's right: a) you don't get scroll events until the scroll has finished, b) you do get touch events that drive the scroll (but nothing during the inertial part), c) the appearance of the page is not updated until the scroll has finished.

You can get around this by using programmatic scrolling (e.g., iScroll, zynga-scroller) but you'll never get quite as nice scrolling as with the native behaviour.

Here are a couple of CS-y but not too math-y suggestions.

Consumer-facing interactive native apps are typically low on CRUD and some of them require non-obvious solutions. You could try to get a job (or just create a product on your own) on mobile or in games.

Another option is working on tools instead of apps. If you manage to get some non-trivial gcc/clang/kernel patches accepted you can try to find a company that works on those.

(I've worked on Google Maps for Mobile and am now building a robotic waste recycler - no CRUD for me since 2002 unless I've decided to build some for my own needs).