HN user
blog.benstrong.com twitter.com/bscode
I generally try to be encouraging of people putting themselves out there to create something new, but I'm worried that you're creating a pretty serious moral hazard for the founders you're trying to help.
It's the kind of situation that can lead well-intentioned people to make bad decisions.
Very cool! Reminds me of all the fun I had with Rocky's Boots on Apple II:
In my experience, it's mostly the situations where people give their emails in person that are a problem: Receipts from in-store purchases (and in-store credit card signups), hotel reservations and rewards programs, EMR signups, lawyers offices, banks, realtors, etc.
Websites are pretty good at verifying email addresses these days. The real world, not so much. The super funny part is when you try to ask the bank/doctor/etc. to stop sending someone else's personal info to your email address, and they tell you they can't make that change since you aren't the account owner.
"One unusual capability of the Snark missile was its ability to fly away from its launch point for up to 11 hours, and then return for a landing. If its warhead did not detach from its body, then the Snark could be flown repeatedly."
I built a service around 2005 that did realtime photo sync and sharing from mobile devices. Here's a demo video from 2007 (the most relevant part is around 6:45):
https://connectedsocialmedia.com/1163/sharpcast-demo-brings-...
For a beginner, I think it's hard to beat "C++ Primer" by Stanley Lippman.
Oh, memories. I took CS107 in 1996, which was apparently the date this handout was written. Nick was my academic advisor, and his CS108 (which was C++ at the time) was one of my favorite courses of all time. Bunny World...
Maybe I'm just a grumpy old programmer, but I feel like kids these days are missing out on something important by learning to program in a language that doesn't require them to truly grok memory management.
P. Terry's serves "all-natural" beef, but it is not grass-fed. If you want a grass-fed burger in Austin, try Wholly Cow (which is quite a bit more expensive than McDonald's, as you would expect).
I highly recommend Honey Stinger Gold. I had trouble with every other gel I've tried, but I can digest the honey just fine, even without water.
I have a Garmin Fenix 3, and the vibration wakes me up easily. It also goes well over a week between charges, even using the GPS heavily. Long battery life is important for a watch you are going to use as an alarm, since you lose the convenience of charging overnight.
I find it interesting that people are complaining both about the lack of a web app and about Google keeping message history on their servers. I'm assuming they will eventually build a web app, but you can't build a useful one unless you have the message history on the server, encrypted in such a way that the web server can decrypt it and serve it to the browser.
Unfortunately, you really do have to choose between privacy and having a web app. I'm not sure which I value more, TBH.
Wow, that was harsh. If startups were assigned to the Deadpool based solely on whether their 1.0 products were ready to immediately disrupt billion dollar industries, there wouldn't be _any_ successful startups out there.
Personally, when I see a team of people who are passionate about what they are doing create something new and interesting, I like to cheer them on.
I think the technology is interesting and cool. Even if it isn't marketable in current form (what 1.0 product is), I wish them the best in iterating on it until it is.
If an employee generated no additional income to it's employer, there would be no reason to hire him in the first place.
The thing to remember here is that hiring managers aren't spending their own money. And most managers I know (though notably not the best ones) have always wanted to manage bigger teams, both for simple ego reasons and because it tends to lead to promotions and higher compensation (in one company where I worked briefly, title and compensation were directly linked to number of employees managed).
This motivation leads to all sorts of decisions that are suboptimal from an economic perspective, including lots of "bullshit acquisitions".
I'm pretty sure we didn't do that. :)
Unfortunately, this is one of the reasons we've been reluctant to publicize GitTogether. You never know if the login will work or the contact list will load.
Not sure what to say about signaling other than handling all the edge cases takes a non-trivial amount of effort and testing (which is true of most things in software).
Chat is only possible peer-to-peer if you don't care about histories. Since losing your history every time you reload a page or close a tab isn't a great experience, it's helpful to have a server in the middle keeping the history, unread counts, etc (which we do support today). Presence will always require a server.
We do run relay and STUN servers in locations around the world. Our STUN server is based on an open source implementation, but it is substantially customized. The relay server is our own.
I can't speak to how the Twilio Client works, but how we're different is easy: We do video. Twilio is only voice.
We don't provide any special support for doing this, but we do give you access to the browser's MediaStream object. You can attach that to an AudioContext and use the web audio API to do what you're asking for.
We ran this experiment a few times and it took most people about a minute to install Skype if they already had an account, and at least a couple if they did not. On many machines (such as mine) it can take 30 seconds just to open Skype.
Good feedback. To address your comments:
>> This just seems like a wrapper around webrtc, with some presence stuff thrown in.
It turns out there is quite a bit of server-side infrastructure required to support webrtc apps. The biggest ones being relay, STUN, and signaling servers. Operating these yourself is non-trivial, especially if you want good performance around the world. We also have a pretty full-featured chat service.
Doing a good job of session management (which is a large part of what our javascript framework does) is also a pretty complex problem, especially doing a good job of handling a single user logged in from multiple devices / browser tabs.
>> Your website does not mention anywhere that the majority of web users do not support webrtc
Good point. We should definitely cover supported browsers. Since full WebRTC support will be enabled in Firefox 21, the majority of web users actually will have support soon. Also, I have no data to back this up, but I have strong anecdotal evidence that users who have webcams and do video chat are much more likely to be on a modern browser.
- Is this a product?
It's a platform that includes cloud infrastructure (signaling, messaging, STUN, and relay), a javascript framework for using said infrastructure in your own web app, and a pre-built "web client" (a skype-like web app that you can use on its own, in conjunction with your web app, or not at all).
>> Why would I use this?
If you are a developer looking to add WebRTC to your app, the answer is that running the cloud infrastructure to support it is hard and costs a lot of money. We take care of those parts.
> Are you actually aiming at replacing skype?
As a general-purpose communications network, no. As a tool that businesses use to communicate with their customers, yes. A surprising number of companies, including a lot of startups, are doing skype calls with their customers, which involves walking them through the install process, adding them as contacts, and then coordinating the call. Everyone who is doing this hates it and is looking for a solution that doesn't require an install, doesn't require a permanent "contact" relationship, and has better call quality.
>> Do you intend on having users embed it in their site?
Yes, absolutely. One of the most compelling use cases is to have customers placing a call from your site, while your reps/salespeople/stylists/doctors/etc are using the "web client" to answer the calls.
>> Make paid chat applications with your platform?
This is certainly possible and is a use-case we want to support, but the bigger problem we're trying to solve is let business communicate more effectively with their customers on their own web sites.
This doesn't make any sense at all to me for generating dynamic html, since the whole page load will be stalled while you run your db queries. Most sites run many queries to generate a page, at least some of which need to be done serially, so you're adding (300ms + WAN latency) * (num serial queries) to the page load time.
If you have a pure ajax app that's directly hitting the db, then it starts to make some sense, as this isn't too much slower than it would be to hit your own service backed by a local db (though 300ms is definitely on the slow side for queries). This seems to be the use case they're aiming for given the focus on end-user authentication.
Fair point. In retrospect, invoking net neutrality wasn't really called for.
I'm not sure how the fact that it's a server-side change makes it ok. I think that everyone would agree that turning off congestion control entirely on the server side would be bad and would negatively impact other flows.
The question, then, is whether this change is significant enough to increase internet congestion (and therefore packet loss for others). This is a subject of heated debate at the moment.
I agree fully. I focused on the front-end because squeezing milliseconds out of the backend is my day job, and I'm pretty confident I can generate pages in < 50ms. Given that, I thought it would be interesting to see just how much I could squeeze out of the delivery time.
It's not tunable at the app level. On linux it requires a kernel patch to change. I'm not sure about other OS's.
I don't like any of the traditional investment options right now. Bond interest rates are too low. Stocks are overvalued. I'd probably put it into an investment I actually have control over: a new startup.
The Android/ChromeOS strategy makes sense from Google's point of view. At this stage in the game, it's unclear whether the future of app development is browser-based or native, but it's incredibly important to get the answer right. So what do you do? If you're Google, you run a big A/B test and let the data decide.
Apple is doing something similar on a smaller scale by investing heavily in both webkit and native apps. In the short term it causes some developer and user confusion, but it's worth it to make sure they aren't left behind if web apps win in the end.
I think the whole point is that being extreme about it turns it into forcing function to make sure that the dev setup process is extremely fast and easy. As soon as you start relaxing the timeline (to, say, pushing code in the first week) the urgency to keep the process fast disappears.
I have a 2.5 year old daughter, and I've found that once we got past the sleepless nights phase, I became more productive on my side projects than I was before she was born.
I have dramatically less free time to work on them, but out of necessity I've become much more focused and disciplined about how I use it (no more tv, aimless web surfing, etc.). The net effect is that I'm getting a lot more done. Meanwhile, my single friends are complaining that they don't have any free time for side projects. Hah.
Actually, while applying a blur does obviously eliminate detail, you can retain most of the important detail with a selective blur. Give it a try in gimp and see for yourself. The default selective gaussian settings work pretty well for de-artifacting, and the loss of detail arguably isn't much worse that that in webp compression. Some of the commercial de-artifacting tools use different techniques (I don't know what they are) that result in even less loss of detail.
To my eye, webp reduces compression artifacts at the expense of losing detail (this is especially visible in the portrait example).
Another way to accomplish a similar effect without requiring a new file format would be to apply a selective gaussian blur (or another de-artifacting filter) to highly compressed jpegs before displaying them.
Of course, no one does that because the trade-off is generally not considered to be a good one.