leothekim

> How can you ever be sure a file exists?

Well I can't ever be sure, but the example I'm thinking of is looking up a config file on the file system that was copied there by a deployment script. If it didn't exist, a RuntimeException failing the application would be entirely appropriate.

If I was checking for a file on a USB drive or some other source, I'd very much have a try-catch. Do I need checked exceptions in this case? Still debatable in my opinion.

WRT checked exceptions targeted for production grade software, curious what you think about the (lack of) checked exception handling in Java 8 lambdas.

I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch. Or had to add an unused throws clause because an interface specified it. Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons of code to uselessly handle the new checked exception or throw a runtime one and catch it at the smaller number of callsites, or throw it as one of the declared checked exceptions that would not accurately describe the type of error to be handled. Anyone use Hibernate and see how many times an underlying SQLException got wrapped by a HibernateException?

For functional programming languages, I think it's a lot more convenient to not have checked exceptions because how they affect the composability of closures. Not saying it's impossible, but imagine having to add throws clauses to your .map and .filter chains.

Ever hear of the phrase "Man's inhumanity to man?" Yeah that's been a thing since, well, humans have been around.

Python is certainly one of the more opinionated languages in the OSS world, so there was always going to be contention on syntax and what it means to be Pythonic etc. Kinda amazing Guido put up with it for this long.

Thank you, Guido, for putting the B in BDFL when you could.

I'm probably being silly, but it is ironic to me that Microsoft will own the service that hosts the Linux codebase.

Aw man so many good moments here. Love the groove starting at 26:31. Eddie Hazel RIP. I view funk in the 1970s as a natural extension of big band jazz, and Parliament Funkadelic was the epitome of that. Jazz is the teacher, and funk is the preacher. Thanks for sharing this!

Why is this important? There are standalone clients for Slack available on Mac, Windows, and Linux.

Serious question: where would one seek shelter if that notification were true?

They've made their share of mistakes, but they've stuck it out and have definitely improved their product over the years. I wish them all the best for their IPO. What would be really good to see As a measure of their business health is an indication of how their cloud business is doing with respect to their enterprise sales business. A healthy cloud business would signal less volatility in the face of high revenue garnered from fickle enterprise sales relationships that have been their bread and butter until the past couple years.

And now the Bloomberg headline for the same link changed to "Blue Apron Is Closing Jersey City Facility and Moving 1,270 Jobs". This is irresponsibly different from the original "Blue Apron Plans to Cut 24% of Staff Barely a Month After IPO" headline.

That headline is misleading. CNBC is reporting this:

"The company's employees were given the option to transfer to the new facility located in Linden, New Jersey. The 1,270 cut jobs indicate those who decided not to transfer, the company said."

https://www.cnbc.com/2017/08/04/blue-apron-to-cut-more-than-...

One risk in buying a huge/expensive house is that you might not use all of it. As a result, you end up paying property taxes and insurance fees for what amounts to underutilized housing space. Then again, if you have the wealth to buy an expensive house, it may not matter as much.

> There's a decent amount that you can do to prepare for one of these things, but there's also an incredible amount you don't have control over.

This is where I call bullshit. This person prepared for six months. You can't tell someone to not take something personally if he or she took six months of their life to study up, only to hit a dead end because your company didn't find it within themselves to take control of the things they could have.

"Additional job-related responsibilities" == We don't want to define this role so we can throw the kitchen sink at you.

(As if this weren't obvious already from the job requirements.)

There is weather, and there is climate. The latter we have very good models for, the former is notoriously difficult to predict.

https://www.nasa.gov/mission_pages/noaa-n/climate/climate_we...

Straw man script about what happens when you "blindly use Hibernate." I suppose there are lots of people in the world who do that. I would think that Hibernate isn't the sole problem in those cases.

Scheduling is hard too. Every company has different requirements around how their scheduling works. Lots of businesses need their employees to clock-in and -out of their assigned shifts for accountability reasons, not sure if Staffjoy supported that. The shifts can have requirements too, e.g. the maintenance shift can only be scheduled for 8 and 12 hours, but nothing longer/shorter. There are usually payroll and billing implications, so adapting to an existing payroll/billing system would be an additional challenge, and not doing so would be a non-starter for lots of businesses.

If anything, the product surface area they were trying to tackle is really broad. Probably could have focused on a particular vertical and provided more value-adds.

I'm excited to see what gets open-sourced. Schedule visualizations are also hard. :-)

Reading this:

http://www.theverge.com/2016/11/8/13561146/tesla-acquisition...

Makes me wonder where this will lead for the workers.

This sounds like a step towards making Slack more of a knowledge repository and possibly a wiki replacement. One of my (many) qualms with knowledge repository tools like Google Sites is that searching them is basically useless. Another is that knowledge in these repos becomes stale really quickly. If you can put meaningful information in a Slack post, you can take advantage of the recency-focused nature of chat and smarter searching algorithms like the one described here, and essentially make an internal Google for your organization. Kudos to the Slack team, very interested to see how this evolves.

The cost of moving software that relies on app engine frameworks is probably the bigger unstated one. Unless you can port those frameworks to your shiny new datacenter with automated deploys, etc, you'd be running two versions of the same code for a while.

Is it not possible to build your own "alternative in the market" for $2 billion?

> We rely on Google Cloud for the vast majority of our computing, storage, bandwidth, and other services. Any disruption of or interference with our use of the Google Cloud operation would negatively affect our operations and seriously harm our business.

Over-under on how much of their cost of revenue goes to Google App Engine?

Serious question - why is cancelling a promise a reasonable use case? Doesn't cancelling potentially invite non-deterministic state into your program? If not, what would be the difference from throwing?

This article made me think of this Gordon Bell quote:

"The cheapest, fastest, and most reliable components are those that aren’t there."[1]

That quote is a reminder to me that there is a certain artistry behind engineering anything.

[1] http://quotes.cat-v.org/programming/

Some interesting thoughts on a similar sentiment: http://mcfunley.com/choose-boring-technology

Nice takeaway: "The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood."

For me it's less about the fragility and more about the grip. My iPhone easily slips out of my hands unless I have a case covering it. I do find it odd that Apple sells an iPhone an attractive finish that people will instinctively want to cover up with a case.

I don't know who you are, but I am giving you the biggest hug in my head.

I'm not sure about testing kits, but there is naloxone, which is becoming part of standard operating procedure in reversing overdoses and is even available OTC in some states. If something is learned from your daughter's death, I hope that the availability of naloxone becomes better known and even more widely adopted.

My parents were devastated when my brother died. Coping with his death very nearly killed my mother, and almost certainly killed my father. As cliché as it sounds, there is life after death, and you have loved ones who will help you through this. Not believing that probably worsened my parents' state of mind. I wish you strength, peace, and light in the coming months.

Got it. I got hung up on the meaning of "optional values", JSONB makes sense for storing arbitrary metrics. Thank you for clarifying!

Maybe I'm missing something, but I think of optional columns as nullable (but declared) values. It sounds like you use JSONB to store arbitrarily declared values. If so, then I'm still confused then by how you're able to hoist values from JSONB data to save on perf and space. That implies these values weren't that arbitrary to begin with.

"For datasets with many optional values, it is often impractical or impossible to include each one as a table column."

Honest question - what settings would many optional values be impractical or impossible? Is it purely space/performance constraints? If so, it doesn't sound like JSONB gives you wins in either of those cases.