Hey! This is a great callout, we'll think about how to make it better!
4,442 karma · joined August 24, 2009
The point of Flat Data is to push the edges of that bubble outwards. Add tooling and examples. Add a viewer. Make the "happy path" situations where this is helpful really fast and easy.
We're pretty upfront about this not being a major technological advance. The difference between a difficult-to-use API and a good API is usually just about the mental model. We like this mental model, and the kinds of patterns it encourages!
There's no GraphQL backend yet! We've only done HTTP and SQL backends so far. If your GQL query is simple enough, you might be able to squeak by with an HTTP flat action whose target is https://your.site/graphql?query=whatever ?
[1] https://alex.github.io/nyt-2020-election-scraper/battlegroun...
There's more than one way to data. We looked at a bunch of them, and the key thing we keep coming back to is git semantics. In many ways, all these other projects attempt to graft git semantics on top of more scalable datastores, allowing you to "fork" your data or roll it back to a given version. Trouble is, these abstractions have subtly different semantics or behaviors. These aren't inherently bad — just not the same as the ones you know from git.
This approach sacrifices "scalability" in order to let you Just Use Git™. It won't work (well) for a larger dataset, but we find that it's useful in a ton of situations.
For example: I have personally shipped bugs to production because my test fixtures had stale example data. I should have remembered to create new fixtures, but I didn't. Flat could have made them for me, on a schedule, subsampling and anonymizing production data as it worked.
It's a subtle difference in appplication. If your goal is to version $BIGDATA, then Flat isn't the right tool for the job, and you should check out Dolt, DVC &co.
GitHub Codespaces aren't generally available yet, but being able to target both "native" VS Code as well as in-browser VS Code with the same extension is super powerful. Expect a lot more from us on that front.
We've also released a pair of little projects re VS Code development that we've extracted from our work:
https://github.com/githubocto/tailwind-vscode: a Tailwind CSS plugin which creates Tailwind color tokens for each of the VS Code theme colors, easing theme-native styling in VS Code.
https://github.com/githubocto/snowpack-vscode-extension-temp...: a VS Code extension template that incorporates the fastest toolchain with the wisdom we've accumulated about webview development.
Our take on this is about "working sets" of data — if you have billions of rows, that's a lot bigger than a working set! At some point, you have to query, filter, and aggregate to get your data down to a chewable size for work.
You can do that in your code too, and sometimes that's absolutely the right approach! But often it's easier to push that work to "outside your code," and that is what Flat is great for.
https://www.amazon.com/dp/0321545613/ref=cm_sw_r_cp_apa_i_wn...
It seems to me like Terraform is good at describing desired deployment shapes and detecting drift between actual state and desired state.
Can someone clue me into why Terraform hasn't caught on as the abstraction above/that drives K8S?
An important reminder that sharp, articulate intellects are everywhere.
https://www.amazon.co.uk/Framework-Design-Guidelines-Convent...
I think I'm in your expected early-adopter demographic. I am a heavy user of Trello, and this smells like a cousin of tools like Trello but with a very different information architecture. I couldn't understand your product and how it would be useful to me without actually signing up and using it.
An introductory blog post is great, but most people are going to discover your product from your product's website. The copy there fails to communicate the crux of your product in the first ten seconds. I'm awash in a kind of marketing babble of your own invention. Loops? InnerLoops? Why should I care about your invented terminology?
Start over with your copy — you've just started out, so it doesn't really matter what was there beforehand. Cut it down to a short 'graf which:
1. Explains what your product does in a concrete way. 2. Shows me where and why I would use it.
You don't need to communicate 100% of what you do or what your product could do. You need to communicate your product's _most important self_ quickly. Stay away from empty banalities about how more and more people are using your product to keep in touch, because that is generic to the point of meaninglessness. Focus on a use-case where your product excels and where you can tell a compelling story. The fact that people could use the hammer you're selling as a screwdriver doesn't mean that you ought to point it out.
Good luck! I'll be signing up and trying your product out.
More than anything, it enabled a pretty unique pedagogical experience. Every week we'd have to make something which related to that week's topic (diffuse/specular shading, geometry manipulation, inverse kinematics, z-buffers, etc). There were no other content restrictions.
To "submit" our assignment, we'd have to publish the java applet on our personal page. Ken would go student by student and open up the week's projects on the projector, then play around with it a little. If you pulled off something cool, you'd talk about how you did it. If you didn't master the thing (happened to everyone at least once), you'd talk about what was broken, and other people would chime in to help you figure out what was wrong. It was fun either way — detective work without looking at the source.
Most importantly, the whole atmosphere was super-collegial. I learned a ton and it felt like the right way to teach computer science — build things, critique, rinse and repeat. I didn't get much sleep that semester ("WHY THE HELL WON'T THIS RENDER!!!111!!!one" was a common refrain in chat with my coursemates) but it was the best class I ever took.
Plus, Ken drives vim like a fucking boss. Like, he'd enter some arcane vim incantation ":ad8723bsd9asasfd" and bam, a ray tracer appeared in his buffer.
> More potential warning signs are individuals who are poor at following up via email, forget when the interview was scheduled, or aren't flexible with an interview time.
Communication is a two way street. If you're looking to hire people remotely and you expect them to simply adjust to your timezone, you're setting up a bad remote employment relationship.
I've worked for years with a 10-hour offset from most of the people with whom I communicate, most recently with Heroku. A large part of what made Heroku attractive to me as a workplace was the pleasantly frank conversation about communication and limits. I'm generally available for meetings (my) 10p-midnight, which is noon-2p in SF. Otherwise, email / trello / hipchat / etc. Obviously, exceptions happen, and they really are exceptional (no "just this week" things that appear every week).
I've spoken to a ton of distantly-remote employees over the years and all of the stories that involved radical timeshifting on the part of the remote employee ended in a move to HQ or burnout and quitting — with a lot more of the latter.
I wasn't part of the selection process regarding Ember, which is the framework powering the entirety of dashboard-next. My personal feelings towards it are pretty ambivalent; as a python guy, I find it tastes a lot like ruby/rails (lots of magic). That being said, Heroku is a growing org, and a lot of people were involved in building out the new Dashboard — the strong conventions of Ember do make it easier for large teams to work together without multiple styles creeping into your codebase.
There's still a lot we'd like to do with Heroku Metrics, but we had to draw the line somewhere and ship a v1 that fulfilled a value proposition. Enjoy it, do (please!) give us feedback, and we'll iterate our way to yet more visibility into your app's behavior.
In the interest of heading off some of the less productive discussion, here are some salient facts:
* Nobody involved is an antisemite
* Nobody involved is malicious
* The date oops was an honest mistake
* The fact that the incident wasn't owned and dealt with is the bigger mistake
* The fact that it's being dealt with now is a _good_ thing. I'm grateful that it's happening.
* I don't have any personal beef with the organizers, and neither should you
Mainly I'm sad to be excluded from pycon until 2016.
http://gist.io/8101758 (the OP's content, but nicely formatted for reading on any size screen, and with attention to typographic detail.)
As a parent who has had the dubious pleasure of flying with children of my own and experiencing the children of others, here's a far more important takeaway:
As shitty as it is for you to experience a miniature crying human, it is ten times shittier for the parents. The emotion you should be reaching for is pity—for the child that can't communicate its desires, and the parents who are desperately trying to divine what baby wants before dying under the weight of every. single. person. staring. at. them.
As for the parents who apparently "ignore" their misbehaving kids—there are no lack of poor parents out there, but more often than not, ignoring is the fastest path to ending a tantrum ("don't feed the trolls"). It's doubly difficult to do when a plane full of people are giving you the evil eye.
US tax laws are inconceivably, horribly bad for expats like me, even if you are just a working dude. The amount of paperwork and headache I undergo yearly just to stay within the law on taxes is ridiculous—that translates into direct costs to me, mainly for employing two accountants (one for each tax jurisdiction). They're constantly communicating about how best to structure things—not so I can save some money on the imaginary millions I don't have, but to simply not be a criminal.
It gets worse from year to year, as the US passes ever more complex tax laws. Some of them are a major financial burden (double taxation). Some of them are just expensive to comply with (accountant hours).
I'm not going to renounce my citizenship anytime soon, and I get that expats are probably a tiny group, but it's a major pain. Almost every other country on earth taxes based on location, not based on citizenship. Don't reside in Germany all year? Great—no taxes, and no state services for you.
Sorry if that's a n00b question, I'm still fumbling my way around the (ever-growing) virtualization / devops landscape.
I've been using cloudapp for the last year, but I'm curious about the dropbox thing.
There's also Servus (https://servus.io/) which is pretty much like cloudapp/droplr but using your dropbox.
Sadly we don't have anonymized ride data, but we do have bike station info for each station over time. Lots of good use we can make out of that.