ktamura

It may or may not. It’s more that google has a poor track record of investing in niche hardware.

Realistically, if it's equal splits, they probably each own ~5% of the company (By that stage, the founder shares can be down to ~20%)

If they are raising $175M, their dilution is probably in the ~15% range, putting their valuation a bit north of $1B.

So, each founder probably is worth, on paper, around $50M right now. Again, this assumes equal splits. It's possible that the CEO has more shares by virtue of assuming greater responsibilities.

If you are long US and/or the logistics portion of on-demand, digitally assisted marketplace economy, it's not a bad idea.

For example, it's impossible to invest in just AWS without AMZN's other business. However, AWS is far less susceptible to the current macro geopolitical instability than AMZN's retail business.

This is not entirely true. Yes, Ballmer made many mistakes, but he also architected one of the most sustainably profitable enterprise software businesses (on the heels of all MS software products we love to hate). These enterprise customers are more than knees deep with Microsoft, and deep account penetration bought at least 5 years for Satya to steer the ship in the right direction (giving up on B2C mobile, Windows obsession, etc.)

One of the most common biases I see in how we assess leaders is how we try to attribute success & failure to a single person at a discrete point in time (ex: Here in the US, the extreme Left claims Trump is taking credit for Obama's foundational effort for the economy while the extreme Right says it's all Trump). In reality, it is never that simple nor discrete but rather complex and continuous.

I have to point out that while their marketing copy claims that they want to know "as little as possible" about their customers, they have Segment's JavaScript tag on thehelm.com

Do you know what Segment does? It makes it easy to send data anywhere -> https://segment.com/catalog

I agree on both. Honestly, much of my long hours were due to my inexperience rather than supernatural productivity. If I were to do the same work with what I know now, I'd do it very differently with far fewer hours (probably).

That said, the point OP was making is that in a startup origin story, there's a significant perception gap between those who actually moved the needle and those who claim to have done so. Those who actually drove the bus and those who rode it. Time and again, I've seen the latter people take advantage of the relative reticence of the former.

It's probably more like, "relative to this guy who tried to kill my company early on and later claimed undue credit for its founding, this dedicated early employee surely seemed like she worked 20+ hour days and sacrificed everything for me."

As a final note, I want to add that if anyone was a “cofounder” of TechCrunch it was Heather Harde. She joined in 2006 but she was in the trenches with the team until the very end, working 20 hour days, sacrificing her personal life and giving everything she had to make the company what it was. Heather never sells herself like Keith does, but she should. Unlike Keith, she helped build that company, and gave way more value than she ever took.

As someone who's also been an early employee, I totally see why Heather does NOT claim to be a co-founder. When you work your ass off alongside the founders, you learn two things:

1. Building a company is incredibly hard.

2. Nobody takes it harder than the founders.

Yes, I have worked hard. In the last six years, I always worked parts of my weekend if not my vacations (which were few and far in between early on). I pulled off all nighters as well as a last minute trip straight from work to close a customer. I fell asleep on my laptop answering support questions. There were many nights of dry tears and waking up in cold sweat from nightmares that were all too real.

But what I went through is a fraction of what the real founders went through. And I saw their ups and downs up close.

Startups are hard. Incredibly hard, especially for those who has to lead the ship from Day One. Early, dedicated employees see this first hand, thinking to themselves, "Man, I thought I had a good/bad day, but they are probably having it better/worse". That's why we never claim to be the "founders".

Programmers continue to discover and re-discover APL and array-oriented programming.

If someone is serious about array programming/APL and wants to make a lucrative career in it, study KDB+/Q/K. There's a small but active community around them.

Just to relate an anecdote: I used to be a fairly active KDB+ programmer in finance but left both finance and programming ~8 years ago. Just yesterday, I got an email from my friend who's building a statarb fund around cryptocurrencies. They were going to use KDB+ and offered me a job for "300-500k base with incentives"...

My friends clearly don't know that I now work in sales & marketing :D

Aside: Roger Hui, the creator of J, is a programming sibling of Arthur Whitney, the creator of K/Q and the founder of www.kx.com

I analyzed Backblaze's business model before. It's quite fascinating. https://twitter.com/kiyototamura/status/934558071019339776

If I had to guess, Dropbox improves their margin by getting people to share files and folders (because that counts toward multiple users' quotas).

As a product marketer, I have to say that the name is very unfortunate.

1. Sundown is the name of a Markdown library written in C: https://github.com/vmg/sundown. That Sundown is pretty widely known and used among Markdown implementers. As such, when/if the OP's project takes off, it is going to be confusing (for awhile).

2. Also, the name itself doesn't strongly suggest that it's an alternative to Markdown. Do recall that Markdown's etymology comes from "(HTML) markup". For the Markdown-implemented-in-C Sundown, the name worked because it evoked its relationship with Markdown. In this case, that's not what the project is about. If the intention was to evoke Markdown, then they should have kept the "Mark" part of it, not the "down" part of it.

I used to use KX/kdb/Q/K daily for several years. I wrote a full implementation of reinforcement learning (15 lines), a lightweight MVC framework (to show reports and tables in an internal webapp) and even a Q syntax checker (abusing table as a data structure to hold parse trees). Good or bad, for the longest time, Q was my "go-to" programming language.

Based on that experience...

1) Yes, but that's not huge by modern standard.

2) Q is a DSL version of K. As others have commented, K is a pretty clean implementation of APL, and Q makes K more approachable.

3) I have to agree here, but Q for Mortals makes up for it.

4) It is really fast. As we all know, a vast majority of us actually don't have terabytes and terabytes of data, especially after a reasonably cleanup / ETL / applying common sense. I suppose it helped that I worked in finance, which meant my desktop had 16GB of memory in 2009 and 128GB of memory on a server shared by 4-5 traders.

Finally, Q was never intended for general-purpose computing nor a widespread adoption. At least when I was an active user, the mailing list had the same 20-30 people asking questions and 3-4 people answering them, including a@kx.com (= Arthur Whitney, the creator). Back then, I'd say there were at most 2-3k active users of Q/K in the world. Now that Kx Systems is part of First Derivative and has been working on expanding their customer base, perhaps they have more...?

but it has serious drawbacks such as the time and CPU resources it takes for parsing and the lack of schema.

Ditto. And if you still prefer the schema-free approach of JSON but with faster encoding and decoding support across all common programming languages, take a look at MessagePack.

Unlike JSON, MessagePack is optimized for speed and encodes common data types efficiently. Unlike Protobuf/gRPC, it requires no centralized schema.

MessagePack: https://msgpack.org/

This article epitomizes the old adage: software engineers are terrible at estimating. I have absolutely no stake in Mixpanel, and it has its own flaws, but seeing something as misleading as this on the front page of HN means I have to write a clarifying, if not somewhat edifying, comment =/

1. Right off the bat, there's the cost of building all of this + maintaining it. Something like Mixpanel at scale requires at least two, if not three, engineers: one for client libraries, one for infrastructure (which the OP blogs about), and another for the web app (dashboard, real-time user stream, etc.) To be sure, not everyone needs all features of Mixpanel. To be really sure, nobody needs all features of any SaaS tools. But if you really want to compare apples to apples, then you have to account for these. To hire competent software engineers who can collaborate closely and maintain a complex piece of analytics software requires at least $100k per year, if not twice that based on locale. That's at least $300k and more like $600k right there.

2. The whole point of something like Mixpanel is to make analytics accessible to non-engineers. In their case, it's primarily product people and secondarily marketing/customer success. In any case, building an analytics/data product consumable by non-technical people is hard and takes way more than assembling a couple of cloud infrastructure together. If there's one reason Mixpanel is still in business, that's because of this.

3. Finally, the OP has a valid point which should have been highlighted more, if not to make their own biases more clear: Mixpanel's diminishing differentiation is dev shops/consultancies' opportunity. It is indeed incredible that a dev shop can build even a third of Mixpanel's functionality by leveraging GCP components. Mixpanel had to build a lot of its core backend systems from the ground up, including its original key-value store. Just this year, they fully migrated to Google Cloud Platform themselves, suggesting that there's really little room for differentiation among analytics vendors at the level of infrastructure components (Mixpanel's arch-nemesis, Amplitude, leverages Apache Kafka and various AWS components, most notably Amazon Redshift, heavily)

With all of this being said, one thing remains true: the most expensive cost of any software is people running them and the dependencies created around them. These may not show up as line items, but they sure are deeply embedded in your total cost.

Treasure Data | Solutions Engineer | Mountain View, CA, United States | ONSITE preferred, Full-time | https://www.treasuredata.com/company/careers/jobs/positions/...

We are looking for solutions engineers to help our global customers use their customer data better. We believe that businesses should own their customer data, not outsource to the Google/Facebook duopoly.

This is a job for you if:

* You have a technical background and interested in leveraging it to create high-impact solutions for customers: many of our customers are household names. The best candidates have a technical background (formal or not) combined with customer-facing experience (consulting, running their own business, etc.)

* You enjoy gnarly technical challenges around data.

* People describe you as resourceful, smart and empathetic (all three are important qualities for this job) * You don't mind traveling: there will be a fair bit of traveling.

About Us:

* Series C, HQ in Mountain View, offices in Japan, Korea with dozens of remote employees

* Active contributors to open source: Fluentd, MessagePack, DigDag, etc.

* Great salaries and benefits

* We invest in our people: most successful managers have been promoted from within

Wasn't part of the original tax reform to repeal AMT? Was that lost in the Congressional aisle?

At Treasure Data, we ingest about 1-2 million events per second. Using your #, this translates to ~6 trillion events per month.

If you (or anyone on this thread) is interested in learning more, please feel free to ping me.

Indeed. Quietly but surely, Apple is changing its corporate policies around developers. We used to never see Apple developers at conferences with an official affiliation, let alone having them onstage as a speaker. I once ran into an engineer at a Ruby conference in which the guy demurred who he worked for, and when he finally told me he worked for Apple, he had to remind me the whole "what I say does not reflect nor represent..." preamble. That was as late as 2014.

Great to see such corporate changes toward developer-friendliness.

I had a similar experience and decided not to buy high-end Android phones: the modular (or fragmented) nature of Android's ecosystem doesn't lend itself for quality end-to-end experience. This is not meant to be a knock on Android. I exclusively used Android for the last 4 years, and I like Google's software, the choices on hardware, etc.

However, when it comes to end-to-end experience, Apple's vertically integrated approach is simply better. This is one of the key reasons I switched back to iPhone recently: I just want my phone to work and to be taken care of when it doesn't work.

This is everything that's wrong about Silicon Valley: we perpetuate the false virtue of overnight success, a flash of brilliance and youthful vision when, in reality, it comes down to years of slogging along, many nights of crying dry tears and adapting to the changing environment continuously.

It's sad because every operator I know knows this yet succumbs to the myth-making "hack" because that's how you tell a "good story" that attracts much needed attention among media and the investment community. Traction, hockey stick curve, growth and all that jazz.

And to be fair, it's not entirely VCs's fault either. They have to deliver on their investment promises within a certain timeline. What's really terrible is that there's not enough discussion about this in the VC-backed entrepreneurship community to accept that this is the "game" that everyone has to play.

Can you please elaborate on why you think BigQuery's streaming inserts are not particularly reliable?

I've heard this from many users through my work on Fluentd (in fact, many end up using fluent-plugin-bigquery because they don't want to deal with the minutiae of insertId and whatnot on their own).

Also, I don't think a lot of people fully understand the quota policy and get tripped up: https://cloud.google.com/bigquery/quota-policy

Separately, you can always use BigQuery's federated query capability of Bigtable.

Yes, and very few people understand what that means (I had to look up, and I am reasonably educated on GCP). This is not necessarily product shortcomings but packaging deficiencies that can be addressed with better product marketing.

For us, latency means the time between when the _event_ actually occurs in real life (user clicks on a button) and when it showed up in all of our analytics integrations (Mixpanel, Intercom, etc.). As developers, this is the definition of "latency" that really matters for us because it represents the minimum time before we can take action on our users' behaviors.

This. I call it "end-to-end latency" and it doesn't get nearly as much attention as it should. This is, by the way, why it's a bad idea to use most OLAPs (like Redshift) as a backend for Segment if you want "real-time" analytics. Column-oriented OLAPs are not designed for real-time ingest because either they don't support streaming inserts (Redshift) or it's not particularly reliable (BigQuery).

You might want to try subscribing to WaPo through Apple News or Google News Stand. They have monthly quotas on # of articles you can ready.

While the principle of "per article" pricing is appealing, it won't probably work in practice: generating content worth paying for is not like spinning up servers because the cost of production occurs upfront _and_ have non-zero marginal cost.

Yes, and you pay in the form of giving away your data to advertisers.

To be sure, WaPo also sells data to their advertisers. At the same time, WaPo has broader coverage and probably needs a larger newsroom as a result. Ars Technica is a subsidiary of Conde Nast, and Conde Nast as a whole has paywalled publications (like New Yorker).

In general, I think it's perfectly fine to promote paywalled content on HN so long as the content itself is good. We have to fund quality reporting/writing, and HN can serve as a curation mechanism to surface "content worth paying for".

Ruby definitely owes a big part of its popularity and awareness to Rails. I think all Ruby committers admit this fact.

That said, Rails is hardly the only framework that has brought Ruby to the communities outside of Japan. Chef/Puppet/Fluentd played a key role in bringing Ruby to the ops world while books like "Understanding Computing" by Tom Stuart demonstrates Ruby's potential beyond web programming.

There's a tangible tension between Rails fanatics and sans-Rails Rubyists, but they have needed each other to get where they are today.

Mr. Kalanick is also dealing with the death of his mother, Bonnie Kalanick, last month, in a boating accident that also left his father seriously injured. The board meeting on Sunday is being held in Los Angeles because in the weeks since his mother’s death, Mr. Kalanick has been spending time with family there, where he grew up.

Completely independent of what's going on at Uber, I sympathize with Kalanick and his family. It's very hard to balance family tragedies with entrepreneurship.

This is a great product idea. If you ask any Excel power users, by far the most time-consuming and hard-to-automate task is text and date manipulation.

The beauty of this product is that its adoption strategy is baked into the product itself: I'd share this with all Excel user friends of mine because I want the algorithm to get smarter, and I might even learn a bit of C# myself so that I can contribute and scratch my own itch. This in turn makes the product better (because of the larger training data), lending itself to more word of mouth.

One concern I have is security: I'd love to hear from folks who built this/more familiar with this about how to ensure the security of suggested transformations.

Now this is going to be a moneymaker, this is a sensible business move.

People misunderstand Google: they offer things for free because it lets them collect data (search, gmail, etc.) or it drives competition out (1TB free for BigQuery, for example).

For everything else, they either shut them down or charge money =)

rsc is one of the most brilliant minds of 21st century software engineering. A very lucid thinker and speaker, too. While not everyone likes stuff he works on (ex: Golang), his insight and brain power are unmistakable.

One such example to me is his overview of Acme: https://www.youtube.com/watch?v=dP1xVpMPn8M

Russ's demo is one of the clearest technical demos I've seen.

Interesting. How bad is it? I rely a lot on Google Docs, and for this very reason (and extensions) I stick with Chrome. But that said, GSuite is such a CPU/memory hog. Gmail, in particular, has been terrible recently to the point where I went back to using Outlook for the first time in 7-8 years.

I was in London a few months ago. I have Android Pay (I'm American) and could use it everywhere [1]. Coffee shops, train stations, supermarkets, even a whole in a wall cafe. Unlike in US, payment simply was not a problem/point of friction at all.

I am really curious what was the thinking behind Square's UK launch (if there was). At least as a business traveler (and admittedly in London, the financial center of Europe), I saw no space in the market for Square to enter.

[1] (The ONLY place I could not use Android Pay was Apple Store)