skysight-inc/HackerNews huggingface dataset:
That's a really good question, and it requires some more context.

First, you have to understand your company from a systemic viewpoint. Break it down, and understand the inputs and outputs of every part of your company. You've got your individuals, your various teams, the people they work with, the systems they build, and the product itself. You can measure the input and output of each of these systems in meaningful ways: number of tickets opened, number of defects reported, raw performance metrics, uptime, availability, quantitative user feedback like NPS, and engagement metrics like product usage or feature usage.

But there are caveats: you can't turn these metrics into goals. You need to lead toward the improvement of the systems responsible for those metrics, with the hypothesis of improving them and ultimately the end goal of providing a high quality product of value to your customers. The metrics are valuable information about how the system operates, not the end goal.

There's another problem: you're absolutely right about quality being fundamentally qualitative. It is, after all, the root of the word "qualitative." That's significant. Quality is the humanity of the engineering game: while you can measure a lot of things toward it, ultimately, as W. Edwards Deming said, "The most important things cannot be measured." It sucks, but it is closer to reality than defining any metric or set of metrics. Instead, it requires leadership and a comfort with doubt and complexity. Here's my answer to a Quora question expressing discomfort with this paradox: http://qr.ae/f5iUg

So it's a bit of a Bermuda triangle. First, there are significant metrics you can measure, and you need to decide which ones mean quality to you and your customers—I promise they exist. Second, you can't aim directly for your metrics, since any large enough organization is highly complex and over-optimizing for a single metric or set of metrics can cause significant unintended side-effects. Third, the most important things critical to quality actually can't be measured; or measuring them would cause more harm than good. This makes for a challenge, and it's why this is such a difficult problem to solve in an organization.

What I'd LOVE to see moving forward is instead a profound comfort with complexity, and an understanding of why numeric metrics aren't always the most vital ingredient to success.
I'm curious - how does the theme stuff interact with choosing different ANSI colors in a terminal emulator? Is it using ANSI colors at all for those complex themes, or specifying RGB colors instead?
Accela acquires PublicStuff
Are there anything similar for Postgre?
The last time a leap second was added, it caused issues with a number of servers running Linux due to a livelock. [0] This had an effect on EC2 [1] and apparently other pieces of software [2] as well.

Nice to see Amazon being proactive about the forthcoming change. Time is just a prime example of one of those things that seems superficially simple, but turns out to be deviously complicated. (If you ever want to bore non-technical types to death at a party, just start talking about the history of time. Bonus points for mentioning the proleptic Gregorian calendar in context.)

0. http://serverfault.com/questions/403732/anyone-else-experien...

1. http://www.techspot.com/news/49229-leap-second-bug-amazon-ec...

2. http://www.wired.com/2012/07/leap-second-bug-wreaks-havoc-wi...
Save Document to MS OneNote Format and Inserting Image into OneNote File in .NET
call it spcap .. the .io is available ;)
It's terrible in the CS field, too—how often on HN do we see papers about some new algorithm, with a fancy demo reel, and no code?

A CS paper without source code isn't science, it's show-and-tell. If all you're looking to do is get hired by Adobe/Microsoft/Google/Apple, fine, but don't insult our intelligence by pretending you're doing science.
I don't think it's possible to literally speed up the way brain processes the information, neurons will probably fire and transmit the information at a constant rate.

So if we want to "think faster" we are tallking about:

- strengthening connections between the neurons

- learning new patterns, so that instead of reprocessing the information(reinventing ideas) brain would "cache" the familiar patterns as memories.

I guess either way, the solution to both things comes down to developing skill. Picking a type of problems and solving them a lot, until brain builds up the circuits for them.

I think that when a person "observes the environment and quickly grasps essentials about the situation" he is simply recognizing a familiar pattern, so to be better/faster at that you simply need to learn more patterns(experience). The same goes for the point 3 - the more often you use/recall some information, the better you will be at it.

Regarding the points 1 and 2 - I highly recommend a book "Serious Creativity" by Edward De Bono, learn and practice skills this book is explaining. This is the best book on creativity I've ever encountered, it addresses exactly these issues.

Besides that, a practical advice would be to remove things that slow you down. Remove anxiety, distractions, learn to focus better. Learning meditation is very useful for that.
I really don't see the method as appropriate for dense urban construction. It seems far better suited to rural spaces with little access to modern building materials. Though this really isn't my bailiwick.

There's a design for dense modern urban areas: it's brick-and-timber multi-story construction. You'll find it evident throughout Europe, with basic designs largely established by the 19th century if not before. The advantage of such construction is that it greatly minimizes land use, and hence transportation, a major concern for urban lifestyles. Designs which require large areas, aren't amenable to dense and multistory construction, and whose construction itselft is disruptive to adjacent properties (digging for earth fill in this case) strike me as a poor fit.

In rural areas it might work, though again issues of moisture and cool climates would concern me.

There's also an existing high-density earth-based construction model, the pueblo:

http://upload.wikimedia.org/wikipedia/commons/9/95/USA_09669...
B.C. doctor says perfect vision possible with Bionic Lens
Easeus Partition Master 10.2 Serial Key Crack Full Download
Why is your comment written with an assumption that one of the great things a person can do is to pay taxes? That same attitude is what got us drug laws in the first place.
Yeah, I can figure out what this does based on past knowledge, but where the hell is the technical explanation? I hate it when projects leave that out. Please to anyone who uploads a somewhat complex to github, describe in your README how your program works.
transportation systems in the US have co-evolved with the growth and spread of its population

For the post-1950 period, I disagree. The car was established. Development followed auto-driven growth dynamics.
If you want to use the API the documentation is not particularly helpful on how to put all the pieces together (though it's not too hard to figure out with some guessing).

I found this sample program helpful: https://code.msdn.microsoft.com/JavaScript-Runtime-Hosting-d...
Look at tweets by Balaji https://twitter.com/balajis I think there may be some hints in there.
The predominant use of credit cards in Japan is ecommerce / online, which is, of course, Stripe's target market.

Japanese have on average 2.6 credit cards[1] and spend on average about $3000 a year on those cards. So yes, they're used less often than in the US but they have broad adoption.

Japanese people often tell me that Japanese don't like to use credit cards. But ask them, do they have one? (of course! they say), do they use it online? (of course! they say). So it's true in real life, not just in this report.

[1] https://www.j-credit.or.jp/en/reports/

EDIT: Ok, are you willing to predict failure for Stripe in Japan? Or do you just like being negative in a way that can't be tested? Their strategy seems sound to me, and I predict success.
(I work at Stripe.) I'd think of Stripe as more than just credit card payments. We already accept bank transfers in private beta in the US and would obviously love to expand this to other countries once it's ready. That said, it turns out credit card payments make up 60% of online commerce in Japan [1], so we figured we'd start with that!

[1] http://asia.nikkei.com/Business/Consumers/Japan-credit-card-...
Hrm. I think you're right. I had gone and looked at the GO license and was rather confused because it looked like the bsd 3 clause to me except for a change directly inserting Google's name into the 3rd clause. Could that be the source of the incompatibility?
What slack are you running? Slack or any web app doesn't take a second to redraw on resize.
Ah, but did you save Malik on that run through?
transportation systems in the US have co-evolved with the growth and spread of its population

For the post-1950 period, I disagree. The car was established. Development followed auto-driven growth dynamics.

Land use is a regional issue at the scale of metro areas (or CMSAs). Not nationwide.

Average annual mileage for the typical American is 15,000 miles/year. That's 40 miles/day, or 20 miles one-way radius. Even assuming no weekend travel (all commutes are work related) you're still at 75 miles, or 37.5 miles one-way.

That is: transportation use is a local phenomenon. Distribution of population centers across the country doesn't matter, land use within those centers does. And those patterns have developed and overwhelmingly been driven by auto use for the past 65 - 75 years, with very few exceptions (e.g., NYC).
Haha, thought the same.
A DSL with a View
You are right. I was remembering that I'd see those three together in the borg file, and was thinking about them being co-located because of that.
about the why, I think the ability to think quickly (in wide breadth and large quantity, even with some shallowness due to time constraint) becomes more and more important in modern times, compared to, say, the Renaissance days, because the vast amount of information available, the increasingly complicated and complex situations we face in work place and daily life, and the fast pace of everything moving at, the subsequent demand for people to handle all these.
The lighthouses seem to have a 90° sweep. The sensors on the Vive headset (but for some reason not the valve controllers) seem to be in 90° occlusion pits. This means that if the two lighthouses are at opposite corners of a (square) room, for the most part no single sensor will ever pick up both lighthouses at once, no matter where the headset is in the room or how it is oriented.

I think that was the initial strategy, but now they are going with a timing based or modulation based solution, and that's why the controllers, which were developed later, don't have occlusion pits. In this interview with Alan Yates of Valve, he mentions timing, modulation, the role of the LED array, and getting rid of the wire between lighthouses: https://soundcloud.com/hackertrips/alan-yates-of-valve-talks...
Dates, times, and time zones, +04:00 tough problems at the intersection of computer science and humans.
I'm not proposing anything. This is a well-known concept among quality professionals. I'm going to guess you have a different specialty.

Google "quality assurance control" and you'll find a lot more, but here's one source:

http://whatis.techtarget.com/definition/quality-control-QC
It seems to me that the main reason for the oddness and un-Deus Ex-ness of the boss fights is actually because the three Tyrant boss fights, and to an extent the Three Little Tyrants themselves, are really modelled on Metal Gear Solid, not Deus Ex. Start with a motley crew of freakish mercenary antagonists; let the player catch glimpses of them in cut-scenes; then properly introduce each one in a boss fight in a traditional sealed boss arena, making the player fear and empathise with the boss as the beautiful doomed monster he or she is before killing them, thus ending each chapter on a note of melancholy and settling doom. Oh, and also chaff grenades are key to beating them easily.
Quality is defined in terms of customer expectations. Certain customers demand more, or are willing to pay more, for higher quality; certain ones aren't.

However, I think most consumer or enterprise software companies greatly undervalue quality and its impact on their competitive value proposition, and especially its impact on development efficiency and speed.

Even if the customer isn't willing to pay for higher quality, your developers are still paying for it with their time and ability to innovate; and your competitors will happily eat your lunch while you frantically hire "better developers" and use up all your time putting out fires.

There is a diminishing return on level of quality and level of QA done; you need to do what's appropriate for your market and your customer expectations. I just don't believe that most companies are anywhere near the appropriate level—not just of after-the-fact testing and best practices, but also in up-front built-in quality, design investment, and debt management.
Perhaps to provide an authentication a security layer for IoT...this sounds like a story you could raise 100M with. See also Vernor Vinge and the SHE
There's a chapter on this in Steven Pinker's English style book. You might enjoy it.

http://www.amazon.com/The-Sense-Style-Thinking-Persons/dp/06...
I'm not sure if the addition of a leap second is what prompted qntm to write about this, but his twitter feed is worth checking out: https://twitter.com/qntm
I've always wondered why system clocks are set to UTC instead of TAI[1]. To me, it makes more sense for OSes to ship UTC as a time zone. Leap seconds would then be tzinfo updates, just like when countries change their daylight saving time. System clocks still wouldn't be guaranteed to be monotonically increasing, but at least there wouldn't be minutes with 61 seconds.

1. http://en.wikipedia.org/wiki/International_Atomic_Time
I've done a wide variety of projects - cross-platform GUI, a windows database kernel implemented as a dll - that is, not a server - embedded storage firmware, mac os x device drivers (kernel extensions).

For some but not all of my projects, failure was not an option. Imagine I lost a disk sector in my storage firmware.
> I could easily beat those 4 with a multitude of examples from both Apple and Microsoft that doesn't mean that any of them are untrustworthy

No, that's pretty much what it means. To varying degrees when you build on top of Apple, Microsoft or Google offerings, you're sharecropping rather than farming. Sometimes, they'll just find that it's in their interest to no longer lease out the farm to you -- or to change the rates/terms.

"Untrustworthy" might be an over strong term, if for no other reason than that invoking "trust" as a relevant concept in this context is probably itself incorrect.
You can use tools like SelfControl (Mac OS, for example) which help remove the temptation for N hours at a time.

Once you set the time, then you can just forget about the time wasters and focus on work.

At first, it can be a bit scary when you're faced with no distractions and to-do list. But it gets easier and then good habits start to form.
It's funny to me that I had to scroll to the actual last comment to find what I suspect is the right answer.
> Japanese people have on average 2.6 credit cards[1] and spend on average about $3000 a year on those cards. So yes, they're used less often but they have broad adoption.

I've never seen a really detailed report that drills down into where people use them. Most people I know with cards will use them (or are forced to use them) for internet/cell phone payments, then pay for anything they buy on their smartphone through the carrier payment system, which is all charged to the card at the end of the month. The phone and plan alone (not counting apps, shopping, etc.) would probably account for $1200 a year on a credit card, which is a significant percentage of the $3000 you're citing and that's not a chunk that Stripe could conceivably take since it's initiated in a real-world transaction at a store and used for e-commerce after that.

I don't know a whole lot of people who actually go around putting their card numbers into sites, especially if they have Rakuten cards -- they just tend to stay in the little convenient walled garden and/or select convenience store or bank transfer payments.

So there are a lot of entrenched "don't worry about it" payment systems that Japanese consumers have already bought into.

> Ok, are you willing to predict failure for Stripe in Japan? Or do you just like being negative?

I'm mostly wondering what Stripe plans to bring to the table in Japan. It's hard to get excited about another online payment processor when online payments here are way easier than I remember them ever being in America. I can order and pay cash for practically anything I want online without worrying about my credit card information being leaked, etc. If I don't want to pay cash for whatever reason, credit cards haven't been difficult to use online; Rakuten makes it just as easy as Amazon does, too. I don't think I've ever had an online shopping experience where I wished there were a simpler payment processor.

I do almost all of my shopping online, so I'd imagine I'm one of the consumers that would potentially be using Stripe, but it's difficult for me to see exactly where it would make my life easier or better. At work, bank transfers are the de facto standard simply for traceability and ease of use.

Edit: Put another way, one of the main problems with American companies trying to come into Japan is that they don't really know what Japan already has to offer or why Japanese people prefer things a certain way, and I'm curious about how Stripe intends to target Japan versus just bringing in an American product and hoping it takes off.
> we really should be limiting those restrictions to the smallest number possible.

Agreed. I was only trying to produce a notion of speech that we can safely declare inviolable. There may be a gray area between that which is certainly black or white. Having those boundaries lets us explore it while mitigating the slippery slope.
You mean replication factor of 3? It doesn't work like that. If your replication factor is 3 and you're using quorum read/writes then as soon as two machines are down some of the reads and writes will fail. The more machines down the higher the probability of failure. That's why you have to start shuffling data around to maintain your availability which is a problem... (EDIT: assuming virtual nodes are used, otherwise it's a little different)
This is certainly an interesting idea, but isn't TAI/UTC somewhat orthogonal to TZs? I'm in America/Los_Angeles, for example, and if I want my time in TAI, my local time would be ~35 seconds different from my local time in UTC, would it not?
Coocoo hashing with a cryptographic hash (+ salt, potentially) doesn't leak any useful information, contrary to what this says.

The only information you get with a lookup in a coocoo map if if either of the cache lines containing the two slots are in cache or not. Which is irrelevant, as to get anything useful you'd have to reverse the hash.

Not to mention if cache is really a problem just use a non-temporal read on both lookups (and always do both lookups, and make sure the hashmap is locked into physical memory). This is pretty close to data-independent time.
I haven't seen a patent application for a time machine, so we can rule out the possibility that they're actually slowing down time.

However, I do wonder how they implement this. Do you change timekeeping in the kernel so that a fraction of extra time must pass for each second to be "counted"?
To add to this, I have not ever taken a programming class - after 1 1/2 years in software engineering, I became a senior engineer. Previous experience didn't really say much about me except that I took on increasingly difficult problems & roles. I knew everything that was thrown at me though.

Smart people aren't quick to judge largely on the past - they take the baseline that they are looking for, set out to gather evidence for and against it, and assess on whether the criteria is met based on a wholesome picture - the past should be a couple of data points amongst many.
100 Years of Beauty
But not a single lookup table. If you can chain lookup tables it's equivalent to any other kind of gate. If you have to process all possible input combinations at once you can't do any meaningful computation.
What an elegant solution. This is really cool.
the title is somewhat misleading; he's discussing crytography.

I'm a huge fan of lookup tables, which can transform any algorithm whose input is sufficiently small into a constant-time operation.
After doing quality for 15 years after another 5 as an application developer, I'm prepared to say that it's an awfully expensive and ineffective way to try to set tone. All it mostly does it get the rest of the company to assume you've got quality all handled and start chucking stuff over the wall at you. It doesn't inspire them to a higher standard.

If QA groups spent half as much time actually testing or helping stabilize development processes as they did maintaining brittle docs they'd probably be considerably more effective. At the end of the day most verbose test docs should have been one set of canonical product docs and a list of inputs/strategies. Instead we repeat and fragment the same info across a bunch of disconnected test docs and then let them rot under the weight of maintenance.

The problem is everyone thinks they have a "one true way." We know that concept is bullshit in software dev and that approach should be tailored to the problem at hand. We understand how important YAGNI and SPOT is, and why sometimes insisting on a perfect architecture is a bad thing in the real world.

Why people think it's any different for QA is beyond me. The same principles largely apply.
Though I agree, I can't help but think of Anwar al-Awlaki [0]--the first US citizen killed by JSOC [1] for what seems to be his expression of anti-US sentiment (and calls for violence against America & Americans). That said, he was a) an American citizen and b) expressing what one might consider his freedom of speech.

Is speech protected only in so far as that we agree with it and that should someone say something we're not comfortable with (e.g., "I hate the US policy in Country X and think the US should be stopped") we should have the right to stop them, or should there be no barriers on it whatsoever?

0 - http://en.wikipedia.org/wiki/Anwar_al-Awlaki

1 - http://en.wikipedia.org/wiki/Joint_Special_Operations_Comman...
The Beginning of the End for Terrible Wi-Fi on Planes
Many games use Scaleform to create UI, which uses Adobe Flash. And I think it's possible to create UI using WebGL for example.

Your comparison is just plain stupid. If you don't want to use these abstractions you can opt out, for the most part.
The themes are specified with RGB colors, and fish tries to pick the closest color supported by the terminal. It can do the 14 ANSI colors and the xterm 256 colors. fish 2.2 adds support for 24 bit color, which a few terminals can do (Konsole, iTerm2).

fish has a set_color builtin which accepts RGB hex. This makes colored output easy: `set_color 69F; echo 'I am light purple!'`
Your figure makes more sense as a per driver figure. There are about 100 million Americans who do not have a license to drive (and reason to believe that most of them do not drive illegally):

http://www.fhwa.dot.gov/ohim/onh00/onh2p4.htm

The passenger vehicle fleet is also about 250 million (estimates arriving at that figure are including pickups that are used as cars).

I guess the typical American might be a modal driver, but it seems odd to use a definition of typical that discards ~1/3 of the population in question.