1) It's pretty clear then that you don't have much experience with planning at level beyond a few people if you've never heard the term KPI come up in software
2) Agile still comes with meetings
HN user
Generally good guy.
Email me at gordon(at)3002(dot)ca.
1) It's pretty clear then that you don't have much experience with planning at level beyond a few people if you've never heard the term KPI come up in software
2) Agile still comes with meetings
If you had no KPIs and no meetings how did you know what to work on and what the company needed? Osmosis?
Feels like this person completely missed the point of choose boring technology. The point isn't to never use anything new or exciting, the point is to save the excitement for your core value prop so that you're not wasting time e.g. debugging why your customer database keeps losing data instead of iterating on your actual product, where all the excitement is.
I wouldn't call that being a crap shield. I'd call that executing on the non-technical aspects of your team's strategy.
When teams don't see (and/or frame) those things as key part of achieving their goals the results aren't gonna be great for anyone.
But doing so wouldn't make that developer's software unusable on Windows.
Just wish these articles would address the amount of content and utility we get in exchange for our data (instead of our money) and speak to the trade-off. Until we find a better way to financially support all of the things we consume on the web, I'm not sure I see anything changing.
I think everyone has their own ideas on who's the victim.
People seem to care about a 70 year old billionaire getting "bullied" by the media for example.
I'm not sure I really believe that.
I can believe it. I once worked at an investment bank where, during bonus time, I needed to deal with an issue at a trading desk. While there I had the following conversation with a particularly angry fixed income trader.
Me: Hey Trader, what's got you so pissed off?
Trader: Just got my bonus. I got 13MM, but Trader2 got 16MM! Can you believe it?! I made way more money than Trader2 this year!!!
Me: ...
His anger had nothing to do with total dollar amounts. It was only that someone he rates himself against made more.Nice problems to have.
How come the millionaire Duck Dynasty cast member isn't an "elite," but everyone brought in by the Democrats was?
The amount of garbage Scala generates doesn't get enough airtime IMO. There are at least five instances I've been part of where an underperforming Scala component was rewritten in Java for significant performance improvements, mostly due to significant reductions in GC.
Not sure if this applies to their use case since they mention FIFO in the context of it being a simple eviction policy, but if you _require_ FIFO semantics then both Redis and memcached are out of the question since they use nondeterministic LRU policies (memcached's LRU is particularly egregious in its nondeterminism due to the way slab allocation works).
The use case in mainly deduplication of a high volume data stream (though it's got a few other uses). The write volume is fairly stable so it's sized in such away that we'll never emit dupes even when the upstream source crashes and needs to be rebuilt from backups (for this case that means > a billion cache entries). Something like the opposite of a bloom filter (https://www.somethingsimilar.com/2012/05/21/the-opposite-of-...) didn't work because we don't want false negatives either. Since the cache is fed by a Kafka log HA is achieved simply by having multiple consumers individually populating their own cache instance. The persistence mechanisms are to allow for code deployments that don't blow away the cache, not HA.
We actually experimented with grid caches (ignite in particular since it offers off-heap in memory storage as well), but the performance simply isn't there. At the volume we're writing even millisecond latency is a non-starter. We did explore both memcached and redis, but we need strict FIFO and both of those solutions provide nondeterministic LRU.
I confronted a similar caching requirement (in my case the cache needs to be much larger) in Java recently and chose to implement off-heap for some of the reasons you mention. It avoids GC and heap size concerns entirely and makes it easy to tune the rest of the application's GC profile. Systems handles 45k writes/sec and about double that for reads with very low latency minimal CPU. Implementing concurrent writes/eviction without typical Java concurrency controls was a bit tricky though.
Project is here for those interested: https://github.com/Maascamp/fohlc
An important difference with the web is the barrier to entry. Testing an idea for the web is orders of magnitude cheaper (time and money) than an idea for an app.
I wonder if this has implications for the higher levels of hypertension found specifically in African Americans.
Just use Windows Defender. It's built in. You're already done.
If you're an enterprise you're using github's on-premise appliance and aren't affected at all.
They were never making money off the pirates anyway. This way they can get more people on their services, on a more secure OS that will be evergreen, potentially paying for extras, and at the very least helping their ML algos.
The "intellectuals" who watch sports are interested in strategy. This encompasses on field strategy, personnel choices, and beyond.
The fact that you ignored (or are ignorant of) this side of sports tells me that you've not actually had much practice "making conversation or building rapport" around sports.
Apple's laptop division and the appeal of OSX have very little to do with these revenue numbers. At 6.9B Mac sales are only a few multiples of Microsoft's fledgling Surface business, let alone the laptop market in general.
IPhones on the other hand...
I'm on the same page. Chrome locks my computer around once a day on Ubuntu. Startup is horribly slow as well.
Is it? It quotes Altman as saying, "Going way out of our way to invite people to apply who don't fit the stereotypical start-up mold has worked really well for us."
Sounds exactly like they're just attempting to cast a wider net. Any other implications you took from that weren't from the article.
If your non-geeky "friends" are telling you to get a life, I suspect they aren't actually your friends.
Wow. What garbage.
The premise of this book seems to be, "We need to stop people with different values from becoming developers (regardless of how skilled they are at actually writing code)." Really? This seems like a tech equivalent, "the immigrants are ruining this county" rant.
Who's talking about shitty startups? I don't live in silicon valley.
Thank you for typing that all out. I agree completely. As a visible minority in tech, I'm simply more attracted to companies where I feel l won't stick out like a sore thumb. Of course I want to hired for my qualifications, but I'm only applying to companies that can meet _my_ requirements as well.
Of course companies should only hire qualified people. Diversity is about gaining new perspectives and ensuring you're creating an environment _all_ your employees can enjoy and feel comfortable in.
Companies, rightly, don't want to stagnate by being limited to perspectives and views that don't fully reflect the world they operate in.
What's another way?
Seems more like iOS 7 is the only convenient thing to do. That's fine, but the current title makes it read more like a weak attempt to justify not wanting to support older versions.
First, great article.
Coming across article now was quite serendipitous as I'm in the process of designing a Databus like system myself. In regards to Kafka and Databus, one thing I've been wondering about is why the Databus relay isn't implemented with Kafka? Kafka seems to provide the same semantics (at-least-once in order delivery, clients can pull from arbitrary positions in the stream, etc.). I know Databus provides transaction semantics in the stream and a few other differences, but those differences don't seem too large. Is it because Databus is to be embedded in Espresso? Or maybe even something as simple as two different teams converging on the same solutions?
Anyway, thanks again for the article.