Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
adamwiggins
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
91.
▲
Show HN: Muse – Tool for Thought on iPad
(launch-preview.museapp.com)
266 points
by
adamwiggins
6y ago
|
188 comments
92.
▲
by
adamwiggins
7y ago
Muse | engineering partner | remote | https://museapp.com Muse is an iPad app for research, deep thinking, and creativity. We're a four-person team seeking an engineer to join as a ful partner in the business. You should be
93.
▲
by
adamwiggins
7y ago
Hi Dale, I'm one of the local-first paper coauthors. I'm a fan of PouchDB (thanks for that) and the whole CouchDB lineage--the CouchDB book[1] was an early inspiration in my exploration of next-gen storage and collab models. I
94.
▲
by
adamwiggins
7y ago
I'm the author of 12factor (although really it is an aggregation of the work and insights from many people at Heroku). It continues to surprise and please me that this piece continues to be relevant eight years later—a virtual eternity
95.
▲
Tablet platform showdown
(inkandswitch.com)
3 points
by
adamwiggins
8y ago
|
0 comments
96.
▲
by
adamwiggins
8y ago
Great project. My team used it for a live-coding Python notebook: https://github.com/inkandswitch/livebook#readme To my surprise it was faster than Jupyter / CPython for some tasks (e.g. loading and parsing large
97.
▲
by
adamwiggins
9y ago
Ink & Switch | engineering lead | Remote | two-month contract | $2k/wk Join our research team to build a prototype pinboard-meets-notes app running on a tablet. You'll help select the tablet development platform (Swift/iO
98.
▲
by
adamwiggins
12y ago
Clue :: Berlin, Germany We're a VC-backed, 14-person team working in the field of reproductive health. Check out our app on iOS ( https://itunes.apple.com/us/app/clue-period-tracker/id657189... ) or Androi
99.
▲
by
adamwiggins
12y ago
Clue :: Berlin, Germany We're a startup based in Berlin with the vision to make a dent in the history of family planning. Currently 14 people, we work hard but are easy going. VC-backed and with a secret hardware project in the works.
100.
▲
by
adamwiggins
12y ago
I'm the author of this article. If you want to know how things turned out, here's a follow-up / debrief from a few months after the first one: http://www.xconomy.com/san-francisco/2014/05/08
101.
▲
Mobile syncing with Couchbase
(medium.com)
2 points
by
adamwiggins
13y ago
|
0 comments
102.
▲
The Product & Feature Lifecycle
(product.adamwiggins.com)
1 points
by
adamwiggins
13y ago
|
0 comments
103.
▲
Prototypes Are Disposable
(product.adamwiggins.com)
7 points
by
adamwiggins
13y ago
|
0 comments
104.
▲
The Basics of Prototyping
(adamwiggins.svbtle.com)
4 points
by
adamwiggins
13y ago
|
2 comments
105.
▲
by
adamwiggins
13y ago
So maybe I'll start making a FAQ for everything. Q. Who is this Adam Wiggins guy? A. http://about.adamwiggins.com/ Q. Why did you leave Heroku? A. It was time to move on. I'm proud of Heroku and everything I've done in the last six years.
106.
▲
by
adamwiggins
14y ago
I totally agree that hacks to avoid idling when are willing and able to pay is lame. We've actually been working on something very similar to what you describe. Send me an email at adam at heroku dot com and I can give you early access.
107.
▲
by
adamwiggins
14y ago
I agree that thinking about memory use steps a bit closer to the world of server administration, which doesn't thrill me. We've actually had 2X dynos in alpha for close to a year, but we never pushed forward with a public release precisely
108.
▲
by
adamwiggins
14y ago
How's this for clear: you get double the CPU share. Happy? :)
109.
▲
by
adamwiggins
14y ago
This is a tough area. If you go look at various types of infrastructure providers (e.g. EC2, Linode, Rackspace) you'll see that they always end up making up vague units of measurement (e.g. "cores") and then showing all the resources in ref
110.
▲
by
adamwiggins
14y ago
There are two separate issues here, and it's easy to get them confused. One is the slow degradation on Bamboo without any change to the routing algorithm code, and the other was the explicit product choice for Cedar with a different code pa
111.
▲
by
adamwiggins
14y ago
We spent quite a bit of time trying to find a one-size-fits-all framework. There just wasn't one, so we've done credits on a case-by-case basis. Sorry you find it annoying. It's what was best for our customers.
112.
▲
by
adamwiggins
14y ago
Yeah, the developer-facing control surfaces on the platform (API calls and git push mainly) have gotten slower over the past year or two. This is on my list of of personal pet peeves, but so far has not made it onto our list of priorities.
113.
▲
by
adamwiggins
14y ago
We might. But what does this actually get us? It helps clear Heroku's name, but it doesn't help our customers at all. I'd prefer to spend our time and energy making customer's lives better. Given the choice between continuing the theoretica
114.
▲
by
adamwiggins
14y ago
> It seems to me that if you split into two (or more) tiers, and random-load-balance in the front tier (hit first by the customer), and then at the second tier only send requests to unloaded clients [...] I'm unclear how you'd think int
115.
▲
by
adamwiggins
14y ago
> What's the constraint that prevents you from having your dynos register with the loadbalancer cluster and then having the latter perform leastconn balancing per application? This is how it works. Dynos register their presence into a d
116.
▲
by
adamwiggins
14y ago
Just in the last few weeks. I won't disclose details for any particular customer, but I assume that Tom @ RG will make a public statement about it at some point.
117.
▲
by
adamwiggins
14y ago
Again, sorry to hear about your bad experience. Hard-to-diagnose errors, no autoscaling or other method to know proper dyno provisioning, and slow deploy times — these things suck. Would love the chance to win back your trust and hang onto
118.
▲
by
adamwiggins
14y ago
This comes back to visibility: knowing where the problem lies (especially when you're using a variety of add-on services or calling external APIs) and being able to understand what's happening, or what happened in retrospect. Visibility is
119.
▲
by
adamwiggins
14y ago
The difficulty of diagnosing H12 errors is really challenging. One thing I can recommend is using the http-request-id labs feature: https://devcenter.heroku.com/articles/http-request-id With this enabled and some code in your app, you can
120.
▲
by
adamwiggins
14y ago
We're aware of the random H12s problems. Some apps are affected pretty badly, others not at all, and we're not sure why yet. Sorry that you've had such a bad experience with this. We're continuing to investigate. If we're not able to find a
More ›