ballard

Yup. Gotta find a problem and a solution and make money at it. Otherwise, it's not survivable.

It depends what net profit % was.

Businesses that lose money on every sale are not survivable.

They need to track all of their costs and see if it's going to be remotely profitable.

I could also get used to delivered deserts.

Esp delivered by quadcopter.

Is there anything similar in Paris already?

Talking to someone in the baked goods manufacturing business might save a whole lot of pain.

Some markets aren't occupied for a reason and others just haven't been explored.

But if it's at all successful, they're gonna get slaughtered by incumbents unless they defend a niche or offer a more compelling "why we make bread" story. (Also the bread kind, not just the green.)

My hats off to folks that execute on something.

What's the end game? It seems like premeditated failure into murderously brutal markets where distribution is painful. If they're going to do it themselves they're going to learn quite quickly that it can only work in about a dozen metros. That's a 20 million a year business with margins that will be tiny....

Doesn't butter my bread.

Seems like a hard to scale lifestyle brand because delivery and manufacturing are going to hurt (time and $). It's more of a fit for Shark Tank after they've tested that it can generate profit.

And if they ask for too much %, just quote 'pg "All we really wanted was your money." :)

Adoption can be modeled to depend on ease-of-use driven by apparent need, influenced by a user's risk-appetite. But also popularity, being a differential equation, where it's rate of change is proportional to the number of users. So if the apparent benefit isn't there, most people being reactive, probably won't use something better, especially if it's as hard to get working as old Postgres... They use MySQL until Postgres demonstrates advantageousness.

Zerigo DNS is free and solid.

GPG in the same boat, and DANE & DTLS.

s/app/lib/

Killing off popular products is one way to keep them cool for a comeback.

Yup. It's configuration management.

A setting maybe needed per app, per process, per thread, per class|module, per subclass|include/extended module, per instance or per method call. (Phew.) And that's probably only 90% of use-cases, not counting apps configured by something like a JSON api, ZooKeeper or Chef databags.

The trick is to isolate config from behavior out of code as much as possible, scala style. An obvious example is to use environment variables so apps can be reconfigured without touching code.

Ran an email hosting service and used zimbra. Email migration (through acquiring failed shops that were tech clueless) and replication is nontrivial because of edge cases. Backup, backup, backup and test a zillion times before doing it for real. Rolling anything your own or using OSS as-is rarely scales. Neither are commercial products.

If anyone wants to see the MVVM (MVCP) pattern in Rails 3 action, the diaspora codebase on github is a good place to look.

We also add our own standards to Rails:

    app/clocks/      # clockwork
    app/hacks/early/ # before boot
    app/hacks/late/  # after initialize!
    app/threads/     # launched in Thread.new to save RAM costs (150 MiB / process)
    app/workers/     # sidekiq

And foreman_god to support passenger-like tmp/stop.txt and tmp/restart.txt

The Fountain

Feedback on this from both sides of the table. Every dev esp. entry level students list the same keywords: Java, Oracle, Apache, ... Zzz.

Recent specific accomplishments that furthered tech or business plz. What makes you uniquely relevant to the role?

Yeah. Depends if the recruiter was retained or contigent.

One of 'pg essays is about this. So finding low risk / low investment ways to work with someone solving a real problem cuts through most of the bullshit.

SRE

Comments that add no value while the hard stuff isn't documented: knowledge hoarding.

Over-engineered, massive codebases: job security.

Site reliability engineering could be an option: fixing other people's code to work and run cheaper at scale.

For devs, it's important to have a github or similar because that's your real tech resume.

Btw I use Perl 7 (Ruby)

ZURB and IDEO too

http://zurb.com/article/11/the-t-in-team

Investor interest and hiring manager interest has this in common: inbound to the candidate is far better than shaking bushes. Even YC alum mentioned how outbound is basically desperate and futile. Not that it can't be done, it's that the probability is much lower.

Cover letter is the TL;DR as how the resume applies to the req with 2-3 top selling points. The resume is like a marketing specifications sheet to sell a phone chat. Etc.

0. Ageism is rampant. A research dept I worked at briefly fired an admin for being "old."

1. Lack of persistence (hustle) on the candidate's part.

2. May or may not have personality or skills issues.

The tangential thought, despite the British humor, is that by embueing devices with AI, users will have to be respectful of devices. You wouldn't want your garage opener mad at you after all.

I was going to say "over my dead body" but then they'll detect when a user dies eventually and somehow monetize and leverage that.

Equivalent of click fraud would be paying people in Africa etc $.0005 / track to listen to your Spotify silent tracks.

I'd like to see something like Arch, Parabola or similar with packages that are source only, signed, minimal dependencies and just works. Oh and push fixes upstream.

(Glibc makes me sad.)