HN user

lxt

269 karma
Posts14
Comments48
View on HN

Hi! My team developed the extension.

The Ad Analysis extension uses two data sources: 1. It locally (on your machine) collects the ads you see as you see them on Facebok and analyzes and aggregates the targeting information for each of these ads. Your data is not sent anywhere. 2. It contains a dataset (thanks in part to the New York Times and Propublica) that shows you who the top political advertisers are on Facebook, how they target their ads, and what those ads are. This means you can see ads that you would not normally be shown.

I hope this is helpful!

Reminding myself that perseverance is the only thing that works.

"Nothing in this world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent." -- Calvin Coolidge

Let's Encrypt was founded by a group including Mozilla, EFF, and the University of Michigan. Mozilla is also a platinum sponsor. So yes, it is a Mozilla project.

Source: I am a Mozilla employee and a board member of ISRG (which operates Let's Encrypt).

We have several different mechanisms for running experiments. The e10s one specifically runs through what we rather poorly named a "system add-on".

e10s code is present in all builds. The system add-on contains logic that decides whether to turn it on or not. The system add-on can be updated daily (or more often), in all channels.

* I apologize for the naming, this is entirely my fault. I spent a lot of the last twelve months scheming/designing and developing experimental update mechanisms for Firefox.

The basic shape of the contract is the same. The publishers I have worked for are both fans of plain language and relatively short contracts, which helps. (Tech publisher is Pearson, fwiw, and they have been wonderful to work with over the years.)

The differences in how I write are pretty epic. For a tech book I'll work out a very detailed outline (down to subheadings within each chapter) in advance, and need larger slabs of time to write to maintain my train of thought. For novels I tend to work from a much lighter-weight outline (major plot points, not chapter by chapter) but spend a bunch of time in advance thinking through the characters and world-building.

I have written some tech books, one of them best-selling, tech edited others, and written a preface for one. I am also the author of published novels.

The amount of money and contract terms vary widely with the publisher. This is where a contract with one of the big publishers is in your favor. You can also consider self-publishing, but that is a different business model, which I will not cover here.

Don't be afraid to ask for different terms.

In particular:

- You can negotiate for an escalator clause on the royalties. This means that the more books you sell, the higher your rate.

- You can ask for a higher advance or a lower advance and higher royalty rate. You can ask for the advance to be split differently (on contract, 25%, 50%, full MS, final acceptance, etc).

- You should negotiate the option clause. This is the clause that says they get the first option on your next book. Specific terms to negotiate include limiting the scope - not "next book" but "next book on the topic of game development with Python". Also make sure they have a limited time to consider your proposal before deciding to buy it or not. 60 days seems to be a common number, but you can probably negotiate that down.

- Strike any non-compete clauses (that you will not write a book on this topic for anyone else or self publish one).

- Strike any cross-accounting clause. This is where you must earn out the advance on every book you have for a publisher before you can receive royalties on any book (and royalties for book 2 can be counted against the advance for book 1, and so on).

Some publishers pay monthly, some pay quarterly, some bi-annually. Take this into account.

Ask your publisher what their marketing and promotion plan will be for the book. How much support are they putting into it?

Earnings vary a great deal, but I have been very happy over the years, and book earnings have paid large chunks of my mortgage. How much you make depends a lot on the size of the audience, what other books are in the market, the timeliness of the book, and the publisher's approach to distribution and marketing. It tends to be on the small side and I realize my experiences are not typical.

It has opened doors for me and my co-author. We've been offered jobs, contracts, writing opportunities, and speaking opportunities.

I would say this was the best career decision I ever made. It's also draining and time-consuming, so be aware it's a large project.

Good luck!

If you are going into a book contract, familiarize yourself with cross-accounting or basket accounting clauses, and get them stricken from the contract. (This is the clause where you need to earn out all the books before getting royalties for any of them.)

In general familiarize yourself with book contracts, and understand the pitfalls. Or consult a literary lawyer.

Source: I'm the author of multiple tech books over more than a decade and several novels.

Definitely this. I fought depression (originally PPD, but didn't go away) without medication for three years. Tried exercise, sunshine, B vitamins, volunteering, etc, etc. When I finally went to the doctor the medication working was such a huge relief, because nothing else did.

This is kind of what we have in mind.

The model is that we want to make Firefox itself more webby in the way it ships. Features should be independently updatable from the core browser, and we should be able to do phased rollouts to help us watch for issues, control for load, and so on.

We are looking at offering very experimental stuff in a purely opt-in process, and updates to regular features as if they were third party add-ons (with some twists in how they have to be implemented).

It's mentioned only briefly here since the email is mostly about XUL/XBL.

I'm working on the Go Faster project. We hope to deliver a 1-2 features this way by the end of 2015. We have just started on building out needed changes to the client, update service, and build pipeline.

This is one of my all time favorite essays. Great to see it linked here. Best part: 'To nine out of ten of you the choice which could lead to scoundrelism will come, when it does come, in no very dramatic colours. Obviously bad men, obviously threatening or bribing, will almost certainly not appear. Over a drink, or a cup of coffee, disguised as triviality and sandwiched between two jokes, from the lips of a man, or woman, whom you have recently been getting to know rather better and whom you hope to know better still—just at the moment when you are most anxious not to appear crude, or naïf or a prig—the hint will come. It will be the hint of something which the public, the ignorant, romantic public, would never understand: something which even the outsiders in your own profession are apt to make a fuss about: but something, says your new friend, which “we”—and at the word “we” you try not to blush for mere pleasure—something “we always do.”'

Selling user data would be completely against our mission and values, and I think it would be extraordinarily hard for such a change to make it through the internal immune system for such things. I think Mozilla is less likely to do bad things with your data than just about any other company (or government for that matter) out there.

(Disclosure: I work for Mozilla. I am helping write an updated set of privacy guidelines for engineering teams, to be as explicit as possible about how careful and respectful we need to be with data.)

Wow. A billion dollars in profit, 12 million in his pocket each year...but the 7 million for health care has to come out of the employees' other pocket.

Also, the fact that he's blaming two babies - I find it highly unlikely, statistically, that two such cases blew the cost of premiums for a group as large as AOL. I'm pretty sure they had more employees with cancer that year, for example, and that's also super-expensive.

This guy is despicable.

Some ideas, from one with a small child:

Lunch breaks are great for side projects, even if you have to go work in your car in the parking lot, or the cafe down the street.

Also, if your commute is via or can be via public transportation, or a car pool, you can work on that.

See if you can get up at 4.30 on weekends as well. I bet your spouse and child don't, so it's an instant extra couple of hours.

Hope that helps.

As mentioned in the article, give up useless timekilling activities (TV, Facebook, etc).

The other big thing for me is cache warming. If you are doing non-mental activities such as showering or driving, use that time to plan what you're going to do next on your project. Pre-solve the problem: write the code, book, whatever, in your head. When you have free time - even if it's only fifteen minutes - dump the contents of your brain into your laptop. Don't spend that fifteen minutes thinking "where was I?" Do that in advance, and maximize your output in short stretches of time.

This approach is literally magical for me.

It's worth noting that yes, it's changed pretty radically since 2009. There is some amazing stuff going on in the PHP ecosystem these days.

I apologize in advance for the hand waving vagueness, but here's how I think of it.

N=abstract thinker, likes ideas and concepts and big picture S=concrete thinker, likes real things and details

J=likes rules and systems and binary partitions P=thinks in terms of guidelines and heuristics and rules of thumb and grey areas.

Most programmers are Ns, but I have met quite a few DBAs who are Ss. I'm a P (could you tell) although close to the middle. I like to make the joke that Ps are always 5 minutes late, but don't think of that as being late ;)

Hope this helps.

The stub itself pulls down the full installer, and you can always get that from download/FTP if needed.

The intention is to provide a better download experience: there was a gap between the number of people who begin downloading Firefox (counted via hits on download.m.o), and the ones who open it for the first time (counted via hits on the firstrun page). The stub installer is intended to address this. It also checksums the full file to make sure you're getting what you think you're getting.

(Disclaimers: I work for Mozilla, and am responsible for download.mozilla.org among other behind the scenes web things. I don't work on the installers, but we had to change the download scripts to support the stub. I do not speak for Mozilla.)

I run the Web Engineering team at Mozilla, which is responsible for our crash reporting infrastructure. I was pretty happy to see this outcome from Sauce Labs :) Stability is something we take very seriously.

If you have questions I'm happy to try and answer them.

Re the headline: duh, I'm reading HN. Anyone who has convinced themselves that this is work is in denial.

I do agree with TOA though. You have to learn to call yourself on this stuff, or get a buddy/mentor/manager who will.

Do first what needs to be done now. The backfill tasks can be saved for when you have a slow time, or really need a change of pace (to solve some kind of long-slow-thought problem, or when you're tired at the end of the day, or whatever).