HN user

vicapow

2,429 karma
Posts56
Comments67
View on HN
twitter.com 10mo ago

Anyone else seeing data disappear on y-sweet from Jamsocket / Modal

vicapow
1pts0
www.reddit.com 1y ago

Use your voice to create research papers

vicapow
2pts0
crixet.com 1y ago

Show HN: AI Latex editor built with emscripten

vicapow
4pts1
apps.apple.com 2y ago

Show HN: A better alternative to Google Saved Places

vicapow
7pts5
testflight.apple.com 2y ago

Show HN: Better search and management of your saved places

vicapow
2pts1
vicapow.github.io 2y ago

The Perceptron – An Interactive Explanation

vicapow
6pts2
setosa.io 5y ago

Simpson's Paradox

vicapow
3pts0
medium.com 7y ago

What the Flow team has been up to

vicapow
44pts10
vicapow.github.io 10y ago

1M taxi pickups in NYC

vicapow
1pts0
gist.github.com 10y ago

Allocating 56GB of memory in Chrome

vicapow
2pts1
setosa.io 11y ago

A Visual Explanation of OLS Regression

vicapow
22pts4
setosa.io 11y ago

Where do betas come from? A Visual explanation of OLS Regression

vicapow
3pts0
github.com 11y ago

Generate your own map of all the streets in America

vicapow
1pts0
setosa.io 11y ago

Principal component analysis explained visually

vicapow
187pts22
setosa.io 11y ago

Eigenvectors and eigenvalues explained visually

vicapow
523pts52
bl.ocks.org 11y ago

A Multi-Layer Perceptron in D3

vicapow
3pts0
setosa.io 11y ago

Show HN: Pi Explained Visually

vicapow
16pts7
setosa.io 11y ago

Explained Visually: Sine and cosine

vicapow
8pts0
setosa.io 11y ago

Show HN: Explained Visually

vicapow
353pts45
en.wikipedia.org 11y ago

Eigenfaces

vicapow
2pts0
setosa.io 11y ago

Gridlock vs. Bottlenecks: A visual explanation

vicapow
199pts17
setosa.io 11y ago

A Brief Introduction to WebGL

vicapow
1pts0
setosa.io 11y ago

Woodcut Data Visualization

vicapow
9pts2
setosa.io 11y ago

Show HN: Visualizing CSV formatting with “fingerprints”

vicapow
4pts0
setosa.io 11y ago

Show HN: Markov chains explained visually

vicapow
1070pts92
setosa.io 12y ago

Visualizing how lenticular lenses work

vicapow
3pts0
setosa.io 12y ago

Visual walk through of Euclid's proof of the Pythagorean theorem

vicapow
97pts27
blogs.kqed.org 12y ago

Visualization: How the Drought is Shrinking California’s Reservoirs

vicapow
7pts2
setosa.io 12y ago

Lorenz art

vicapow
1pts0
setosa.io 12y ago

Visualizing conditional probability

vicapow
4pts0
Prism 6 months ago

Hope you like it :D I'm here if you have questions, too

Prism 6 months ago

I'm not against typst. I think it's integration would be a lot easier and more straightforward I just don't know if it's really that popular yet in academia.

Prism 6 months ago

Yes, but there's a really large number of users who don't want to have to setup vscode, git, texlive, latex workshop, just to collaborate on a paper. You shouldn't have to become a full stack software engineer to be able to write a research paper in LaTeX.

Prism 6 months ago

Users have full control over whether their data is used to help improve our models

Prism 6 months ago

I could see it seeming likely that because the UI is quite minimalist, but the AI capabilities are very extensive, imo, if you really play with it.

You're right that something like Cursor can work if you're familiar with all the requisite tooling (git, installing cursor, installing latex workshop, knowing how it all works) that most researchers don't want to and really shouldn't have to figure out how to work for their specific workflows.

Prism 6 months ago

The deeper I got, the more I realized really supporting the entire LaTeX toolchain in WASM would mean simulating an entire linux distribution :( We wanted to support Beamer, LuaLaTeX, mobile (wasn't working with WASM because of resource limits), etc.

Just a suggestion: The github permissions your comment login thing requests is a bit too aggressive.

This application will be able to read and write all public repository data.

We have a few different ideas but hoping to get signal from the folks here on what people would like to see.

Some sort term ideas:

* Auto-categorization. We're seeing most people just have "starred" places, and that's really it, so having some way to suggest a better breakdown of places should locations.

* Adding the ability to sort results by various criteria (distance, recently viewed, rating, alphabetical)

Some longer term ideas:

* Making the experience more social, but more like "iMessage" social not "Facebook" social, if that makes sense.

Once you start importing your saved places, it may take a bit of time for them to show up but once they’re there, you can add notes, add to lists, search through your saved places by note, category, list, visited / not-visited or star rating.

I built this for my fiancée who wanted these features but I’m looking for feedback on how intuitive it is for others as well to see if there are any other features folks would like to see.

Thank you for checking out the App

If you use Google Saved Places a lot but feel it’s lacking some features I’d love to connect with you.

If you’d also like to try out an alternative, here’s the TestFlight download link for an app I’m working on before it gets released to the App Store

Some features: * Import your saved / starred places from Google * Search your place notes * Filter by list to find places you’ve saved again. * Search by your personal star rating or if you’ve visited the location. * [Your future feature request here]

for giving it a try

I like it. It means if someone breaks into the car they can’t get into the glove box. Also, with a Tesla, the car is never off so you don’t need to turn the car on again to get access to it.

Apologies, lxe. I can tell you're frustrated. If the the Flow upgrade process has been burdensome to others, I'd really like to know. I've always thought we've done a good job of updating internally on the platform team and that it hasn't been a concern for end users. We did run into some pain points in changing configuration options around the unnecessary optional-chaining lint rules but that wasn't related to updating the Flow version. I think you may be conflating those.

I’m not sure I agree. I’ve found updating Flow in a rather large monorepo a relatively straightforward process. The changes are usually rather small because the team releases every two weeks. They also manage the update internally within their company’s monorepo so they’ll usually find out about these types of unexpected behavior changes before the community does.

That said, we do rely on automated error excludes (similar to eslint-ignore-next-line) for things that cannot be fixed with codemods. Those errors were always there it’s just now you know about them. Better to stem the bleeding by updating the type checker to the latest version.

There is not a 1-1 metric for "coverage" across these two systems. For exmaple, TS believes this code is "covered" but Flow knows it's not safe:

type A = { readonly prop: number }; type B = { prop: number };

function func(f: B) { f.prop = 20; return f; }

const a: A = { prop: 10 }; func(a); // no error?

I've worked both at a large company (Facebook) that used the mono repo approach as well as a large company that uses the per project repo approach (Uber) and I have to say I'm personally a VERY big fan of the project based repo approach but every company is different. So is every team. If you're a small company with primarily one service and primarily in one programming language, the mono-repo way seems to be the best approach. On the other hand, if you're a company that has embraced a service oriented architecture, the per project repo approach is likely the way to go. Especially if your company is OK with services being written in a variety of different languages and so long as it is as easy to use open source code as it is to use third party code written within your org. It also goes a long way in supporting local (ie., laptop) development. Otherwise, the entire codebase would be too big to fit in RAM.

Disclaimer, these opinions do not necessarily represent the opinions of my employer.

Also, if you're in SF and are interested in learning more about d3.js, one of the primary libraries that we used to build EV, we'll be teaching a 1 day workshop May 2nd geared towards people comfortable with data but haven't gotten deep into web programming. We'll also be using "explorable explanation" style techniques along the way.

Have a look at our preliminary workshop demos for an example: https://vicapow.github.io/d3-1-day-workshop/

I promise the demos will get more advanced and start incorporating data before the workshop :)

You can apply to the workshop here: https://docs.google.com/forms/d/1VgBUu7znZVllkVw2d6TISzsTjGD...

The application process is to ensure everyone's at about the same level. If you're accepted, the ticket is $99 and includes food and refreshments.

I think it's important to remember that, for at least EV, these explanations aren't intended to stand on their own. There's a lot of good resources online already for learning this stuff. The problem, as we see it, is one of motivation and curiosity. If we can help people intuit what's happening and why it's important, we think this will help motivate people to want to get more into the details on their own.