It's a travel tool for business travelers that figures out your suggested departure times for your entire itinerary based on predicted traffic patterns. Think Flighty but for all the non-flight parts of your trip.
You first build a travel itinerary with your legs - flights, activities, hotels (and hotel returns) and it tells you things like "leave your hotel at 7:40am" before your 8:30 meeting - in a single itinerary, no need to do the google maps acrobatics for every two items in your itinerary.
While it's aimed at frequent business travellers I personally use it for all family leisure travel and daily itineraries around town as well - "do I have time for lunch at home after my son's class or should we bring packed lunch".
I built it as during my time working in developer relations I traveled a lot, and always built unnecessary buffers and kept nervously glancing at my watch or phone to see if my planned time to leave still holds.
Tech-wise, currently it's Remix web app with a NodeJS/Fastify backend and Supabase for storage, and relying on google maps for route duration calculations. I want to expand it to native mobile clients in the future as well.
I am using it as playground on product thinking, ruthless prioritisation based on user benefit, figuring out unit pricing and economics, sensible architectural design, and exploring how including AI-enhanced features here and there can help make the product better, not just include them for their own sake.
Ha, great question. We didn't have access a SABRE system so the lookups are fake. I was just about to go in and change it in to a 388 (my favorite plane!), which I think flies daily between LHR and SFO as BA286.
~Unfortunately, the output is in png format which was generated by carbon.now.sh, so I'll have to type everything out. I'll change it once I have a few minutes...~
Edit: just changed it into BA286, which is an 388. (For fun, I also added in first class fare buckets, which United no longer offers.) For additional accuracy, I also updated the UA equipment to 772s, which IIRC is what they actually fly (as opposed to 77Ws).
(If we did this more often, we'd probably actually design it in HTML instead of using Carbon, but an image was much faster, haha.)
- Netflix shouldn't charge cards without verifying email addresses. Security should be an integral part of UX, and not subservient to it.
- Individual email address canonicalisation/resolve _could_ actually be a standard. I'm not sure whether it is or not, but if we can agree on emoji we could also maybe agree on something that binds the internet together. Email is infrastructure, Netflix is not.
- There is still a potential issue by having configured catch-all email addresses on some domains, but we should in that case optimise for the hundreds of millions of gmail.
Frankly this title is worthy of the Daily Mail. I expected more of GitHub.
It merely describes one individual proposal currently going through the process of consultation before being debated in the parliament, nothing else.
This is a fair point. However, it is still a (bad) proposal and while it is possible to hope that policy makers will make the right decision on their own, some public pressure does not hurt.
This may be unlikely to pass as is, but the trend of stifling new software and algorithm development in the name of copyright (or security) is pretty strong. IMO it is worthwhile to push back using chance we have.
Some things shouldn't even be proposed. If someone proposed to kill old people, he would be fired or even arrested. Same thing should happen here. But no, idiots and evil people can propose all kinds of evil stuff over and over and over, until it passes.
Why? Many reasons, but "it's just a proposal" is one of them. It's never just a proposal a proposal and since these people have huge responsibilities they should use their brains or it means they are evil and must be punished.
I initially felt the same way, but after actually reading through the GDPR materials, and a bit of Q&A on HN, I've come to the conclusion that it's a good thing.
It doesn't really place any burden on business - it simply means that you must be transparent with users about how you use their data, allow them to know what data you hold about them, and allow them to delete it if they wish.
As a consumer, as well as a founder, that seems very reasonable.
But the biggest real problem is that since the GDPR, read literally, is borderline draconian and the defence is that the regulators will enforce it selectively and pragmatically, literally no-one really knows how great that burden will be... which itself then becomes a significant burden.
I'm afraid I completely disagree, especially with "borderline draconian".
When I first heard about it, I was somewhat fearful of the unknown, imagining I was going to have to 'waste' time on 'checkbox compliance' - but after spending some time reading about it, I believe the intent is good, and also that the burden isn't going to be that big.
As a consumer, I absolutely want the GDPR - I believe I do have a right to know how my information will be used, to know exactly what is held, and to have it deleted if desired.
As a founder, I want to be responsible with personal data. And because I am, I'm already compliant with just about everything needed by the GDPR. I hardly expect a deluge of requests from users, so I don't even need to spend any time on automation.
Moreover, as a founder, I couldn't agree more with being responsible about working with personal data. We have always been careful about the data we collect and how we store and process it. But from what we have learned ourselves so far, we seem to have significant additional obligations under the GDPR (for example, being able to produce substantial amounts of formal documentation to the ICO on demand) that we would not currently be able to meet, and we might have other obligations that could be awkward (often related to the various subject requests now possible) but the implications aren't fully clear.
We also don't expect a huge deluge of requests from users. In fact, we've never had any under existing data protection rules. However, given that there several people have posted to HN recently saying that they'll be happy to send in large numbers of such requests when the GDPR comes into effect just to make a point, and unlike the current data protection rules in the UK there appears to be no provision for a token fee to deter such vexatious requests, we have to consider the possibility and at least have some intelligent way to respond, even if that just means knowing what our actual obligations would be if anyone did make such a request without doing any other work in advance.
It's a travel tool for business travelers that figures out your suggested departure times for your entire itinerary based on predicted traffic patterns. Think Flighty but for all the non-flight parts of your trip.
You first build a travel itinerary with your legs - flights, activities, hotels (and hotel returns) and it tells you things like "leave your hotel at 7:40am" before your 8:30 meeting - in a single itinerary, no need to do the google maps acrobatics for every two items in your itinerary. While it's aimed at frequent business travellers I personally use it for all family leisure travel and daily itineraries around town as well - "do I have time for lunch at home after my son's class or should we bring packed lunch". I built it as during my time working in developer relations I traveled a lot, and always built unnecessary buffers and kept nervously glancing at my watch or phone to see if my planned time to leave still holds.
Tech-wise, currently it's Remix web app with a NodeJS/Fastify backend and Supabase for storage, and relying on google maps for route duration calculations. I want to expand it to native mobile clients in the future as well.
I am using it as playground on product thinking, ruthless prioritisation based on user benefit, figuring out unit pricing and economics, sensible architectural design, and exploring how including AI-enhanced features here and there can help make the product better, not just include them for their own sake.