45 karma · joined December 8, 2016
Reading more than a sentence caused my eyes to sort of glaze over and even when trying to focus I was reading but not grasping. Can't say I've ever had a font do that to me.
I think we're storing about 20TB of daily and image backups on B2 right now, all done through CloudBerry for Windows Server or Linux.
Workday:
[06:40] - Wake up, check a few headlines and get ready for the morning
[07:30] - Head to work, drive if my partner and I are carpooling, catch an Uber otherwise
[08:00] - Arrive at work, greet a few people, complain about someone forgetting to schedule the coffee pot. Check HN, Reddit, and a couple news organizations. Reply to a few important and/or quick to answer emails and Slack messages.
[09:00] - Get my hands dirty in whatever projects we have going at the moment, field emails and calls as they come in.
[13:00] - Working lunch, reply to emails and try to get some HN in.
[13:30] - Meet with CEO or whoever needs me then spend some time with different departments and jump in to help wherever I can be of use.
[15:00] - Start wrapping up for the day, clean around the office and lay out an agenda for the next day.
[16:00] - Head home
[16:30] - Power nap
[17:30] - Figure out where I misplaced my Blue Apron recipes and make dinner.
[18:30] - Usually try to get some work done, otherwise grab a controller and find a game if I'm feeling particularly uninspired.
[20:00] - Grab drinks at the dive with friends or co-workers.
[22:00] - Head to bed, get ready to start it all over again in a few hours.
It's not glamorous, but I've been fortunate to develop a schedule that keeps me productive the entire work day. There's only so much head-down work you can get done in a day, so taking the last few hours to help out in other departments and take some load off them keeps me engaged and always learning something new.
I also appreciated that I could walk away at any point and pick it up later. I didn't feel "trapped" having to finish a mission like too many AAA games. Well worth the ten bucks in my opinion.
If you feel you can trust a datacenter, the most trustworthy approach would be running your own OpenVPN instance in another country.
Although if you don't want to go through the hassle and do decide to put some amount of trust in a VPN service, I have found That One Privacy Site [0] to be a great resource for researching VPNs.
- Ubuntu on my desktop and laptop
- CyanogenMod on Android [0]
- VPN to a non-14 eyes country [1]
- uBlock Origin, PrivacyBadger, Disconnect
- Null-routed most CDNs (e.g. Google APIs)
- Gaff tape over device's cameras if I couldn't physically disable them
Now obviously those measures go far beyond protecting you from just ISPs, but it was designed to take into consideration every method ISPs, big tech (Google, Facebook), and governments could track you.
[0] https://en.wikipedia.org/wiki/CyanogenMod [1] https://en.wikipedia.org/wiki/UKUSA_Agreement
Most times they're asked to hold the dog in it's crate and walk through the basic metal detector instead of a full-body scanner. In the 15 or so trips they have gone on in the last six months, they've never once been stopped for enhanced screening.
I can appreciate the flexibility you're offered even with the A-list clientele you have. In a world of "move fast and break things" I've re-worked that into my own mantra of "move fast and make things better."
In fintech we can't afford -- both figuratively and literally -- to break things, but you still have to allow your teams to take a crazy "bar napkin" idea and run with it without a bunch of red tape or you lose the competitive edge that makes you stand out.
Now changing the wording on a link isn't a crazy bar napkin idea, but it still demonstrates the flexibility you're afforded to make things better and I see a lot of value in that.
Russia is only mentioned once in the article.
I'm not talking about their write-ups and descriptions -- which I sometimes find sensationalized -- but the raw data. I don't remember any instances where they have published falsified information.
In a perfect world engineers would have to request elevated permissions from a manager/team lead to query tables holding financial information, but in our un-perfect world that's usually not feasible.
About 15 minutes later I got an email from an engineer saying my request got caught right in the middle of an upgrade and that's why it failed.
Great service and a fast response time, but I'm curious how much information is shared with the engineer when that happens? Considering that happened automatically without me requesting help, I'd hope extremely limited information (and absolutely no financial information) is given to the engineer assigned to the ticket.
How much information can an employee see about a particular user? How about when an error occurs? Is it possible for someone at Penny to see financial data, and if so what is the process for an employee querying that information about a user?
I tinkered with building a budgeting app (think Simple's Goals feature but for any bank) and used Plaid. They were a super helpful bunch and the service "just works."
Along those same lines, I think it's great you're using Cordova. Sometimes people feel the need to do everything "the right way" because otherwise they won't get funding / their app won't take off / etc. In reality, there is no right way and you should use the tool that will do the best job for you. Sounds like Cordova was the right move here.
Congratulations on a really awesome product! I'm jealous I didn't think of it first :)
My first thought was that it would be fantastic in a case where I needed to pull a file off a server I was SSHd into but didn't feel like setting up a SFTP session. Of course, in that case I probably wouldn't be comfortable having the data pass through a third-party.
We don't even want _one_ of them. It's not like we're going to see a new printer in a catalog and say "hey, sounds like a great buy!"
Similarly, bigclivedotcom[1] does almost exclusively electronics teardowns. Usually cheap gadgets from Chinese eBay sellers. A lot less profanity than AvE too, haha.
Unless we invent seriously good wireless charging, I just can't see that happening. There's too many cases where having your phone "docked" just doesn't work.
Personally, I usually fall asleep with my phone laying on the bed next to me playing YouTube/Netflix/etc. No way to do that if it has to be resting on a pad like the Watch.
And what about cars and navigation? Can't throw your phone in your cup holder and pull up Maps anymore. You either need a new car with wireless charging or need to strap some sort of wireless charging pad to the back, which defeats the entire purpose of wireless charging.
It appears that once this process is done by the exporter, both your public and private snippets are hosted on the exporters server and accessible without any authentication.
For example, this is an export from the exporter: http://fotis.co/snipt/export.php?user=3760&limit=100
Increment ?user=3760 by 1 and you are greeted with someone else's export.
* Websites do weird things with textareas. If it's a plain-ol HTML form, it's pretty easy to intercept and do what you want. It seems most websites intercept button clicks then pass your text around to twenty different JS functions and libraries before doing something useful with it. You wind up writing code to handle edge-cases more than anything else.
* To address your final comment, embedding the pubkey inside the text would defeat the entire purpose. A malicious actor (see recent Reddit controversy) can just create their own pubkey, sign the modified comment with it, and noone would be the wiser.
Some things I discovered, and found worked well:
* Keybase has a fantastic library for generating PGP keypairs in-browser. It really added that extra bit of "magic" to the extension.
* Chrome extensions can get CORS exemptions on a per-website basis, and uploading to a standard SKS keyserver is just a POST request that can be done by Javascript.
* Expanding on the last bullet point, verifying other user's comments was tricky. During development, I just downloaded all keys on the keyserver that were uploaded by my extension on a scheduled interval and stored them in localstorage. Unfortunately, I don't think this would scale.
If anyone is interested in picking up where I left off, I could upload the source to Github.
If you have any private snippets you would like to keep private, using this exporter would be a bad idea.
If you're the developer of this utility, my recommendation would be to generate a 1-time download link for the snippets instead of hosting them online without any authentication.