skysight-inc/HackerNews huggingface dataset:
Ask HN: Best way to expose data in an enterprise app?
Hi all,

Our sales and post-sales teams get a lot of questions regarding how can they report (think Tableau) on top of the data generated by the use of our enterprise application. We currently have CSV and Excel exports for a smaller chunk(view) of data, but that seems limited.

Now to go forward, there are multiple ways, but it boils down to exposing via API or exposing via a connector (ODBC, JDBC, etc). Correct me if I am wrong here. For B2C, API hands down wins, for B2B, how should we decide which is the best route? If we did go connector route, should we shortlist one or build multiple popular connectors? Did anyone face similar predicament? Any references/links are welcome as well!
Looking at figure 2 in the paper you were mentioning helped me a lot in understanding his thought process.
There was an article written by a guy from the Larrabee team, where he explained how the projet wasn't a failure, in the sense that management wanted a processing beast and that's what they got, not a GPGPU.

Great. Except the kind of parallel processing Larrabee was supposed to provide isn't something anyone wanted.

It's a half-pregnant architecture. Not parallel enough to compete with GPUs, not enough single thread performance to compete with Intel's own CPUs.
It is insane. And it is entirely fueled by access to cheap money. Rates for the past decade has been near 1% and only recently started climbing but still below 2%.

I can't speak for Apple et al but for some companies it has been a tool to raise their share price. With shrinking outstanding number of shares financial ratios like EPS etc start to look big even when the company isn't actually growing. And that means over time these companies can borrow even more money on their "growth". The cycle repeats.
For being able to be processed it needs to be plaintext.
It is not strange if you think of objects in OOP as modules/packages you can inherit from.
I will check them out. Thank you.
I've been working with RN for a few months now. Good luck with that. I can't imagine another layer of abstraction.
Cars need roads to drive, but drones can literally go anywhere.
Macedonia Gets New Name, Ending 27-Year Dispute with Greece
Even many engineers fail to account for the environmental externalities, which I must be part of any "full cost" model.
New Distro Release: Systemd-Free Debian-Based Devuan 2.0 ASCII
Yay! Now, if Trump would just spend that money he was going to subsidize coal mines with on training the miners to build, install, and service solar cells.

The green energy revolution is one of the biggest economic opportunities in the history of the world. Are we going to let China have the whole thing?
If you're going to flog your pet project repeatedly, you should at least provide a substantive response around it. This comment provides no value. It's just an ad.
> Why this instead of say Electron

The major difference is that Electron is a way of wrapping a webapp with access to the filesystem, etc. via Node, and React Native is a way of instantiating, styling, and manipulating actual native components with JavaScript.
You’re not doing it wrong; perhaps you’re more worried about how others will treat you because you feel you’re lacking friendships?

Most, if not all, would watch you bleed out: its the bystander effect. See the Kitty Genovese murder. Are you bothered by this?

You could have died. I fell and hit a glass table too and now I have a scar right next to my eye, less than a finger width away.

I could have lost the eye but I don’t like to think about it either. There’s a lot of stories where I could have been maimed, and I do have injuries that have left me weaker.
This would be academic if someone hadn't actually died. I don't know the numbers, but I'm fairly sure that just tanked the self-driving stats pretty hard.

EDIT: Also, consider what avoiding "hard braking", which was a large reason for human interventions iirc, actually means. It means either that the computer jams on the brakes hard for no reason or that it only realized it needed to brake substantially after a human would have realized the necessity.

EDIT2: Uber had driven 3 million miles at the time of the death according to the below article. A single incident does not statistics make, but based on the NSTB analysis so far, that version of the software made a systematic error. That puts Uber's score at very handwavy 33.33 per 100 million miles. I'm sure the number will change with software revisions and just from random chance. https://www.nytimes.com/2018/03/19/technology/uber-driverles...

EDIT3: I should mention that I was initially hesitant to compute this "statistic" because it's so raw and will wildly fluctuate. Interventions are more solid statistically. I don't think it's crazy for someone to look at a heavy box of metal that requires constant supervision to do the right thing and conclude in the absence of (appropriately) extensive testing that it's dangerous.
PubSub and how BrowserStack uses it
Go 1.11 is already feature freeze and it doesn't seem likely.
It's another example of Daniel Micay (strcat) contributing technically to something, having a falling out with other folks involved with it, then quitting in a huff.
Reminder that Python 2 dies in 18 months.

https://pythonclock.org
The trick to this is find a company with large upside potential that is either about to IPO or has just recently IPO'd.

The list is small, but there are some obvious choices, even now.

Tangentially, I _really_ lucked out. I had other options that were lead engineer, or engineer #2-4, but this was unequivocally the best choice. The work is more interesting here too.
Whats scary is that many of these USB fans could be just normal fans, but there might be one or two that contain malware that either governments could use to their political advantage.
It's normally in an attempt to "build once deploy everywhere" using tools first built as web technologies. The same selling point as the JVM for Java. In some ways Electron serves as a bit of a JVM for web, but then, that is also the utility of a browser. You can see it as an artifact of the web technology coming first and trying to port it backward to other devices. I wish we had ported some of the awesome GUI libraries from native languages forward to the web instead, perhaps when Web Assembly is ubiquitous we can finally have some coherence in tooling.
> Most companies do it regardless of whether it is creating or destroying value, based only on whether they have cash authorized to spend.

Do you have evidence of this? Shareholders vote on what to do with the corporation's money. I would expect the vast majority of those decisions to be rational.
>f you thought music streaming exclusives were bad, just wait until Comcast starts windowing SNL sketches to keep people on its pipes while AT&T only streams CNN to AT&T phones, while Verizon keeps wielding mobile access to NFL games like a club against the American consumer.

Such an anti-consumer dystopia :( It is truly sad to see these markets devolve into such terribleness when there is so much possibility to be had with such incredible technology.
Did you start developing apps, like yesterday? Patterns such as MVC have been around for decades and used in many different platforms such as web and mobile and did not need anything like Redux or Flux. Are there new problems that cropped up recently that needs Redux or Flux? It is youngster devs who haven't seen anything more than React that makes statements like "not using Redux will just bite you in the ass a year down the line".
Nice to hear Stripe being proactive before what is essentially functionality breaking changes. Kudos to you guys for having a page with instructions on testing it ourselves on production servers with small snippets of pre-written code.
I'm confused. Wouldn't "native" imply it uses platform widgets rather than HTML?
Umm...so who pays for cleanups and other damage in situations like Fukushima? Perhaps you should read this article before trying to promote something like this: https://www.scientificamerican.com/article/clearing-the-radi...
The new design tools on the block
All turing complete languages can be used to do whatever we need, doesn't mean all of them are usefull to keep using in 2018.
If I was trying to attack somebody through this route, I wouldn't just release all of them containing malware. Rather, I would target 2 or 3 journalists who I wanted to monitor and hope that they wouldn't be wise enough to consider the security implications. Most fans would check out as being okay, which would lessen the suspicion.

The only way you could definitively tell that these fans are compromised is to consequently check every fan out of the bunch.
From a moral point of view there is. My point is that from the point of view of science the same self-correction should work in both cases, so the bigger story to "somebody lied" is that "in case of this attractive lie the self-correction didn't work well".
> Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers.

I've only ever packaged in-house (within a company I'm working for) Python apps, very simple opern-source apps and libraries and modified existing packaging for new versions of such open source code that otherwise already had available packaging [1], but my experience has been different to the point that I disagree [2].

Since I'm a sysadmin and not a developer, my strategy was not just to use the documentation, but also to look at how other packages handled certain situations, especially if I knew of an app that was relatively complicated in terms of build process. For Python, that was mostly a challenge of unravelling each developer's build/install instructions (easy_install/setup.py/pip) into something that matched an existing debianized Python package.

> Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers.

As a sysadmin, I object to the characterization of the debian package system as being "of a different era", mostly because I don't believe there's anything about this era, nor about dynamic languages (which have been around for a very long time anyway) that has eliminated the needs that it addresses.

That robustness is achieved because of the requirement of up-front effort to conform to a standard that has remained stable across eras.

> What if I want to package a software written in another dynamic language which was invented a month ago?

Same as for every other language since the beginning of time: put in the effort (including asking for help from the community) and conform. If you need a language-specific standard (such as the OS-default for egg-equivalents), then make one up (consistent with other languages) and get your new language's community behind it, if that's possible.

Of course, the other option is just to exist exclusively within that language's ecosystem (e.g. pip, gem, cpan) and wait for other interested parties to do the OS-level packaging for you. That happens, too, but it can slow adoption if your "market" is production environments and not just other devs in the ecosystem.

[1] Although sometimes with inadequate/inaccurate "debianization" (e.g. missing expicitly listing a depency)

[2] I do agree that the documentation isn't necessarily organized in the best fashion, nor that the latest info is in one place, but it's out there. There might also not be One True Way, but it's arguable if that's a bad thing.
Such a preference ordering has nothing to do with real numbers or expected values, though. Orderings don't by themselves lead to real numbers without some sort of countability or Archimedean requirement, and they certainly don't lead to expected values without quite a bit more.

(IMO Savage's Theorem[0] provides a better foundation than VNM, but that's nitpicking.)

[0]See my article on it, if you're unfamiliar: https://www.lesswrong.com/posts/5J34FAKyEmqKaT7jt/a-summary-...
What the other replies said.
Interesting. Fundamentally, in order to achieve async io, a continuation is necessary. Syntax may hide this (e.g. async/await), or make it apparent as in callbacks/promises. I can't blame JavaScript for not having syntax that makes async pretty.

That being said, if we're talking not about IO, but about cpu/memory bound problems... Well I'd be lying if I said it was uncommon in my career to come across people who assumed, to the detriment of simplicity, quality, and performance, that a calculation (e.g. process a list mapping op with AsParallel/parallelStream) would be aided by parallelism. That is just ignorance by Dunning-Kreuger devs who don't apply a critical eye to their own experiences.
You have to really want an anti-Google story to find it in this, the bit where Google is using its market position on the server and clientside to help make sure vendors don't break the TLS standard.
This isn't really the situation. The old code does not have to handle any new elements. It just has to compare (1,3) to (1,2) and send (1,2) the same as before. It has to look in an explicit list of optional items, and skip over all the optional items it does not know, and include only the ones it does know. This is all trivial and many implementations get it right. You don't need fuzzing for this part. Any remotely sane code would work just as well for (1,4) or (2,0).

There were probably some problems with odd dumb custom-coded gadgets. But mostly, the problem is with "value-add extra-security" boxes in the middle that don't _do_ the protocol at all. They are not a TLS client or a TLS server. They are a product which promises to spy on the traffic and "stop the hackers". They really can't do anything useful. They just see that the handshake packet had (1,3) instead of the familiar (1,2) and drop it. For good measure, they also block packets between those endpoints for 24 hours (so fallback retries don't work). Also they didn't add (1,3) to their recognition system a couple years ago when tls1.3 was in the works, because anyone buying or selling these things is just not very on top of things. So, all the middleboxes which are popular enough to matter, need to be tricked with obfuscation, so they're _really_ not doing anything.
There's not a lot of consensus about what primitves good *-native framework needs, implementations are often pretty tied to specifics of the JS libraries they were built to be driven by (go figure), and the whole niche is still discovering what the right tradeoffs might be. On top of that, the technology atop which the star-native frameworks are built is moving forward too. Seems reasonable to expect that eventually a good non-DOM standard for these things might eventually emerge but I suspect it wouldn't be for a while .
Are you sure about that? It would appear that the library will raise an APIConnectionError, which may in turn do so based on the return code from Stripe's API.
My other thinking is ROI. The people with the $100 Android phones were perceived as more likely to watch a black-market broadcast.
It would not be a good idea in Portuguese speaking countries (mold).
> privacy is inefficient. This is the main reason I despise it.

Certainly not in all cases, maybe not even most? For example, it's efficient to have a private key to log in to your server rather than just leaving it open to get hacked. It's efficient to have a private email inbox so your bank login doesn't get stolen. It's efficient to have a computer you can audit and control the software running on, so that your computer and data don't get compromised. Etc.

Everyone would be screwed without privacy. Being screwed is inefficient. This is the main reason I despise it. For people to move from more secure to less secure systems and paradigms in the name of "total transparency", they would need some assurance that they wouldn't be screwed. And I don't know if making an assurance like that is mathematically possible.

> It also seems obvious that privacy is unsustainable and likely to disappear in the future. Knowing this, we should prepare for it. I don't see many people talking about this.

This may seem obvious to you but I don't see any evidence for it. For one thing, how can you (even approximately) "measure" how much privacy there is? Privacy is by definition what you AREN'T able to see or account for in your ("total transparency") system. So if for example SMSs, IMs, emails and phone calls all become "totally transparent" (i.e. not secure), then we still have no evidence that privacy is "likely to disappear", because, for example, anyone can still just write their ideas in a physical notebook, and we have no idea how much this happens.
Well, it seems like a basic problem that everyone runs into pretty quickly when they start putting components together. Think of an Android RecyclerView created as a web component which lets you scroll through a large dataset. The parent component needs to be able to pass a reference to an array of content. This can be done programmatically easily enough, but not in a declarative way.

(BTW, lit-html is really well done. I look forward to seeing its progress - LitElement could really be the underpinning to a standards-based competitor to React, which is a very welcome thing in my opinion.)
3rd party browsers get JIT JS compilation (and have done since iOS8[1]). You’re stuck with WebKit unless you’re a proxy browser though.

[1] https://bgr.com/2014/06/04/ios-8-safari-and-webkit-performan...
Exposing API is the way to go for enterprise as well, however it makes sense to have some sort of API management layer in between (APIGEE, Mulesoft, Dell BOOMi etc) if there are going to be multiple APIs to be exposed.
How does an educated slave happen? Does someone somehow throw money at educating a slave child? Or does an educated person get enslaved?
It would be a rather poor OS indeed if it couldn't host a server.
This page is a good start, it discusses the differences in detail:

https://vuejs.org/v2/guide/comparison.html

My personal experience wasn't that positive with React and then, the whole treatment of JSX as a first class citizen isn't really my style (although you're allowed to use React without involving JSX). Vue just feels more mature (personal opinion) and much, much easier to reason your code about, down the line in 6 months.

I've had super-complex apps that required so many nested components and I had no problem picking them up after about 6 months. With react, you have to be careful as it's easier to shoot yourself in the foot (personal opinion).

Also there's flux, redux which do require a bit of a learning curve if you want to architect your applications using them. Vue has something called Vuex which again, in my opinion is slightly friendlier to beginners.

I re-wrote my entire teaching syllabus for my programming course to use Vue instead of React, simply because it's much better to maintain Vue apps rather than React apps after 6 months, which is the most important value add for me in any framework.

Anyone can pick up a trendy new JS framework and hack a TODO app over the weekend these days, but if you're working on client side, or some serious projects that require long term commitment and maintenance, then you will realize it's more important to consider the framework's maintainability and code readability. For me, Vue triumphs React in this aspect easily.

So, there you go.
Knockoff? Infinipath used Infiniband at first because we could only build one chip, not a host adapter and a switch. Turns out that Infiniband is flexible enough that we kept on doing that for several generations.
La Liga Soccer League Turns App Users into Piracy Spies
I know a lot of people have mentioned that they have transitioned to using the iPad and even making it their main computer but having owned and daily use an iPad Pro (the 10.5 inch), I don't see it anything other than a media consumption device (which I love using it for).

I occasionally used it to carry with me at work, when I got it new last year, to try and make it my "laptop" replacement. I used everything, SSH to log into my Mac back home, I was on irc, browsing the web, writing emails on it, even used Pixelmator and iMovie to edit images and movies for real work things, which my colleagues were impressed by.

It was difficult, however, and I felt like I was constantly fighting with the iPad.

For example, Spotlight just isn't as fast on the iPad like it is on the mac. Try it out. Type command + Space, then type "me" and hit Enter. If you thought you'd get Messages, you will only be right half the time. Enough to make it frustrating. On the Mac, I can fluidly bring up Spotlight, hit a few characters and launch that app. On the iPad, sometimes, it'll miss typing the first character as spotlight animates, and even if it caught the first typed character, it takes painfully long to update results. So by the time you type "me" and hit return, the results haven't updated to show Messages.app yet, and Messages won't be launched.

There's no Xcode on it yet, so I can't code on it properly. There's no terminal, Files.app feels like a poor man's Finder, there's no indication of focus and when you have two apps side by side, there's no way (that I know of) to switch between them using the keyboard. So you have to tap.

So I gave up. I'm sure my experience, needs and workflows are different and maybe the iPad-as-a-laptop is not for me, but I am a bit skeptical now whenever someone tells me they use their iPad as their only computer. At least, not this version. iOS on the iPad at its current form just isn't convenient to use as the only computer.
I wrote my personal website on an iPad Pro. Worked well.

I work on it while commuting on the Tube, where an iPad is less ostentatious than a laptop. It’s built with Jekyll, so I pull the latest changes before leaving the house and then push once arriving at work. Netlify runs the build and the changes go live.

I use Working Copy for Git plus the built-in editor is okay, IA Writer for Markdown, Autodesk Graphic for vectors and Affinity Photo for images.

It’s actually possible to run a full Django dev environment, including localhost in Safari, using Pythonista and StaSH (shell for Pythonista). It’s genuinely amazing what it can do.
I think economists generally agree that a flat per-head tax is regressive and bad policy.

If you're going to tax workers, why not a progressive income tax?
This is a really interesting find.

To be clear on what is happening here:

Method 1 (Information Retrieval): Aristo generates candidate answers (essentially by substituting the possible answers into the question). It then uses information retrieval (ie search) on a set of pre-validated legitimate sources, attempts to find the sentence with closest alignment to the candidate answer and then builds scores based on that alignment.

Method 2 (Topic Matching): I haven't studied this enough to understand it

Method 3 (Tuple Reasoning): They use open information extraction on a set of pre-validated legitimate sources to build tuple statements (think RDF), then use logical inference over them.

The problem is that the pre-validated sources include large amounts of discussion of white supremacy. Someone debunking it (as Ravi Gandhi did in his statement "History is full of such prejudices paraded as iron laws that men are superior to women; that the white races are superior to the colored") uses a phrase which causes problems in all three of these methods.

It's really hard to know what to do here. I think if I was building the system I'd try to detect that kind of pseudo-science question and refuse to answer it.
Yes, but as opposed to a traditional GUI SDK, it's manipulating those widgets with JS, within a Vue.js architecture.
It looks like Vue Native is a wrapper around React Native UIs https://github.com/GeekyAnts/vue-native-cli (in the README)

I personally am following/want-to-use https://nativescript-vue.org/