HN user
http://kaspa.rs
That’s just not true. I’m from Europe but lived in Boulder for several years. For example this shooting (1) happened 5 min walking distance from my home. My kids’ school had several lockdowns due to gun-related stuff in the neighborhood. Something like that is unimaginable in Europe, and big part of why we moved back.
You can pan by holding down Space key (and then use mouse to drag the board). In general Whimsical's UX patterns are quite similar to Figma, Sketch and other UI design tools.
(co-founder of Whimsical here) Thanks for the mention! Couple fun facts - Whimsical is written 100% in Clojure and we are self-funded (https://whimsical.com/business/why-bootstrap/).
Thanks for the mention! We built Whimsical for a simple reason - all the existing diagramming apps had poor UX. It didn't feel like any of them were really optimized to visualize ideas as quickly as possible while make the result look decent.
Similar story here - started with DraftJS but it was kind of cumbersome. Slate in comparison is much more flexible and we've been using it in production for almost a year now. In fact we just launched a sticky notes project management tool which features a smooth rich text editing based on slate https://whimsical.co/sticky-notes/
It's an extension to re-frame that we built. It addresses some of the (subjective) shortcomings of re-frame, mainly the over-reliance on keywords. We'll be open-sourcing it soon.
Indeed, most of the application logic is in client side. In fact it's built in a way that it could function as a standalone application without backend. Currently it doesn't persist the data locally but that could be easily added.
The backend serves as a fairly generic datastore with an API that allows data to be easily synced back and forth. It implements a logic (again non-specific to Whimsical) for how to handle concurrent updates (basically it implements CRDTs). I believe it's pretty similar to Google's Cloud Firestore - we might have chosen that if it was out of beta and we didn't mind the lock-in.
Two main reasons we did this: 1) to be able to easily add offline mode - we don't have it yet but it's fairly easy to add now 2) to minimize effect of network latency on user experience
As for less load on server & cheaper infrastructure costs - you are right, that is another benefit.
We use combination of Redis pub/sub and Websockets. Each document has a unique key and whenever any of the users/clients make a change to it, it's published via that key. Other clients connect via WebSockets to backend and subscribe to the same key in Redis. The notifications are fairly simple.
The complex part is how we sync actual data from clients to server while ensuring consistency. We basically store all data in a tree format and having a diffing logic how concurrent changes can be applied conflict-free in most cases. I'm considering writing a separate post on that.
HackFwd was one of the rare accelerators that was actually pushing the envelope instead of being copycats. Besides they had another rare trait in this space - integrity and deep commitment to companies they fund (disclaimer - I'm the founder of one of those companies).
Actually we did an extended A/B testing on this and video only version outperformed the one with text and illustrations.
> I loathe seeing *.html in urls and that's the only thing you can do with S3 root object
You can configure name of index file, and that will be displayed for requests against root URL and subdirectories (such as blog posts) as well. No need for having .html in URLs.
The only problem I've encountered with S3 web hosting is that it does not let you host naked domains.
Exactly, the best interface for kitchen-ware is physical knobs. I hate all those touch-surface buttons that usually come integrated on stoves like this. They have no feedback and they fail to react more often than they do.
So you can get a relatively high-end induction stove from AEG for $1000 with a similarly minimalist design. Um, $3000 for touch screen?
We are building something exactly like that (native for mac first). You can sign-up for beta here: http://www.cobookapp.com
Most enterprises have a very strong culture of maintaining status quo as extensively as possible. Especially in IT departments. Even big software enterprises rely on 5-10 year old infrastructure software (such as Exchange 2003) which was released during the era of Windows domination. It doesn't help that some of the software is web based because even that is often made for Internet Explorer only.
Nevertheless Mac's are actually spreading in enterprises. Not from top but from bottom. Officially unsupported, but with a help of VM software such as VMWare Fusion there are no problems using legacy stuff.
5000 tasks per day is of course far from limit. we used to build Mysql queues that process close to 100 tasks per second.
The article didn't mention the main advantage of storing queues in DB - transactions. Say you need to update other records in DB while processing a job with 100% consistency. If it's all in the same DB you can update both job as well as data in a single transaction.
+1 for kneeling chairs. I've Varier Gravity Balans http://www.varierfurniture.com/Collections/Human-instruments... and it totally rocks once you get used to it.
You are right. I just spent 25 min on a phone with them and I'm pretty much were I was. Hoping it will get escalated now...
ps. I could use Skype for cheaper calls but they are not very reliable. I have been using Skype for conf calls for ages so I should know
What do you mean by "author say t it's pointless to wait for the financial information to clear"?
I'm not sure I said anything like that.
ps. yes of course it's slightly emotional, we are just humans
Ok turns out the support phone numbers were well hidden http://developer.apple.com/contact/phone.html
Ok I'm feeling slightly stupid now but I couldn't locate dev support phone # anywhere http://developer.apple.com/support/
Also, I don't think it's very clever to make cheaper support channels (email) so bad that the only option is the phone support (which is much more resource intensive and costly). Even when you can afford it...
I guess not everybody caught the irony
I think you are missing the point.
Fixed. Thanks for the tip.
This was a quick 15 min hack last night based on the new API. It's different from the original bookmarklet in two ways:
1) If the URL is already added to HN, it will go straight to disucssion thread, without automatically voting
2) If the URL is not yet added, it will ask if you want to submit it
For example what's the difference between "filter[queries][]" and "q" arguments for http://www.thriftdb.com/documentation/rest-api/search-api? The way I understand, q does a simple keyword matching on all fields while "filter[queries][]" is more like SQL "where" query. In that case, what operators are supported?
Original HN bookmarklet already works that way http://ycombinator.com/bookmarklet.html
However - I don't always want to upvote a post just because I want to check the discussion. Published this with an assumption that I'm not the only one.
There is already JSONP support, see callback argument:
So after some quick hacking I created a new HN bookmarklet based on the new API:
http://kaspa.rs/hn-bookmarklet/
If the current URL is added, it will go straight to discussion thread (without voting). If not, it will ask if you want to submit it.