lylepstein

Tatari | Engineers | Toronto | ONSITE | Fulltime | https://www.tatari.tv

Tatari combines old-school TV advertising with modern tooling and analysis. We build software to automate and improve our media buying operations, and we develop novel statistical analyses to make TV advertising as measurable as digital advertising for our clients, displayed via a beautiful dashboard. Lots of data, wrangled via Python and TypeScript.

We're currently ~35 people, profitable, and growing our business like crazy. We're building out our Toronto office in addition to our existing San Francisco and Santa Monica teams, due in no small part because it's a great city (I moved back here specifically to start this office because I love it here, even the snowy winters).

We have roles open for senior Backend and Frontend engineers, as well as some more jack-of-all-trades positions for a client-facing engineer, and an internal tools engineer.

More details at https://www.tatari.tv/careers. Please email hn@tatari.tv directly with your resume or questions!

Tatari | Engineers | San Francisco | ONSITE | Fulltime | https://www.tatari.tv

Tatari combines old-school TV advertising with modern tooling and advanced analytics. We build software to automate and improve our media buying operations with a relentless drive for efficiency, and we automate novel statistical analysis to make TV advertising as measurable as digital advertising for our clients, all displayed via beautiful dashboards.

We're a relatively new startup, but we're profitable and growing our business like crazy. We have roles open for senior Backend and Frontend engineers, as well as some more jack-of-all-trades positions for a client-facing engineer, and an internal tools engineer.

More details at https://www.tatari.tv/jobs. Please email hn@tatari.tv directly with your resume or questions!

Tatari | Engineers | San Francisco | ONSITE | Fulltime | https://www.tatari.tv

Tatari combines old-school TV advertising with modern tooling and advanced analytics. We build software to automate and improve our media buying operations with a relentless drive for efficiency, and we automate novel statistical analysis to make TV advertising as measurable as digital advertising for our clients, all displayed via beautiful dashboards.

We're a relatively new startup, but we're profitable and growing our business like crazy. We have roles open for senior Backend and Frontend engineers, as well as some more jack-of-all-trades positions for Sales and Tools engineers.

More details at https://www.tatari.tv/jobs. Please email hn@tatari.tv directly with your resume or questions!

Tatari | Engineers | San Francisco | ONSITE | Fulltime | https://www.tatari.tv

Tatari combines old-school TV advertising with modern tooling and advanced analytics. We build software to automate and improve our media buying operations with a relentless drive for efficiency, and we automate novel statistical analysis to make TV advertising as measurable as digital advertising for our clients, all displayed via beautiful dashboards.

We're a relatively new startup, but we're profitable and growing our business like crazy. We have roles open for senior Backend and Frontend engineers, as well as some more jack-of-all-trades positions for Sales and Tools engineers.

More details at https://www.tatari.tv/jobs. Please email hackernews@tatari.tv directly with your resume or questions!

Tatari | Engineers | San Francisco | ONSITE | Fulltime | https://www.tatari.tv

Tatari combines old-school TV advertising with modern tooling and advanced analytics. We build software to automate and improve our media buying operations with a relentless drive for efficiency, and we automate novel statistical analysis to make TV advertising as measurable as digital advertising for our clients, all displayed via beautiful dashboards.

We're a relatively new startup, but we're profitable and growing our business like crazy. We have roles open for senior Backend and Frontend engineers, as well as some more jack-of-all-trades positions for Sales and Tools engineers.

More details at https://www.tatari.tv/jobs. Please email hackernews@tatari.tv directly with your resume or questions!

Joins like that wouldn't really be used for coordinating between multiple threads in a fine-grained fashion. For example, maybe you'd kick off two worker thread from your main thread, and each of those is going to do some fine-grained processing on some shared set of data. The main thread needs to know when that process is finished, so it joins both threads.

I worked in an org at Yahoo that required all development to use Atomic, and that was essentially the reasoning as presented. The Atomic authors put a lot of effort [1] put into proving the size point, enough that it was pretty difficult to argue with. The stylistic issues were sort of swept aside; less size == faster page loads == more revenue.

If you believe the size argument, and care more about short term revenue over developer productivity or happiness, it makes sense, I guess.

[1] https://acss.io/frequently-asked-questions.html#what-are-the...

Size. Using styles like this lead to a small decrease in page size, which over time on a very high traffic site leads to a notable bandwidth savings.

... or at least, that was the argument. In practice, most teams didn't adopt it unless mandated from above; because it sucks to use, has an infinitesimal decrease in individual page load time, and the bandwidth savings certainly don't outweigh the lost developer time.

But hey, all you gotta do is convince some VP that your niche approach is the right one, and you'll get some adoption in a large company like Yahoo.

I believe you can, though I haven't tried it. Typescript will actually give you completion support for plain strings inside that switch statement, which is normally what I go with.

Tagged unions are indeed pretty helpful for Redux reducers. One thing to note is that you can actually skip some code here as well. Specifically, the constant definitions:

  export type INCREMENT_COUNTER = 'App/INCREMENT_COUNTER';
  export const INCREMENT_COUNTER : INCREMENT_COUNTER = 'App/INCREMENT_COUNTER';

  export interface IncrementCounterAction = {
      type: 'App/INCREMENT_COUNTER',
      by: number
  };

Seems like a riff on the famous Perl Compatible Regular Expressions library (http://www.pcre.org), which is used in a bunch of high-profile things (PHP, and Apache Server, for starters). Kind of like "less" vs "more".

So a bit of an inside joke I guess, but most people familiar with regexes will probably have heard of PCRE, so it's not a terribly obscure reference. I liked it :)

Yeah. In my experience, Heroku starts being a drag at moderate scale:

1. You still have to worry about your systems, as Heroku has its own outages, not to mention the other pieces of your infrastructure like DBs, queues, etc.

2. Architecture flexibility goes way down, as vertical scaling isn't a real option on Heroku (and a surprising number of problems can be easily solved in the short term by just throwing big iron at them).

3. The premium you pay on the hardware you're using starts to add up, especially when you're in the realm of "let's solve this problem in the short term by throwing machines at it."

Of course, that's not to say you can't use a hybrid approach of, say AWS + Heroku to solve some of these, but it's a bigger hurdle to clear if you've outsourced all your systems work to Heroku from the beginning. You suddenly find yourself having to figure this stuff out at some level of scale, vs growing it organically and learning as you go.

Does this mean Realm would be usable for Xamarin-based apps in the near future?

Heroku prices are per "dyno" which are significantly less powerful than an EC2 small.

Use CSS transforms. Unlike absolute positioning, percentages with a transform bases the resulting value off the transformed element's size. So something like this:

  figure figurecaption { 
    transition: all 0.4s;
    transform: translateY(100%);
  }
  figure:hover figurecaption { transform: none; }

There's still a lot of differing behavior in modern browsers that a feature check doesn't expose. Bugs, quirks, performance characteristics (e.g. slow SVG animation in Firefox), and just plain divergences from the spec.

HTML5 media is my favorite example of this: mobile devices will actually straight up lie to you when you call certain methods.

If you're making even moderate use of any HTML5 features, you're going to end up doing user agent sniffing.

I think quirks is understating it. The problem with appcache is that if you run into many of those gotchas the article lays out, it's often difficult to resolve them for previous users. For example, say you accidentally give the manifest a far-future expires (gotcha #4); users with the forever-cached appcache need to manually clear their cache in order to get things working again. And, depending on how you've structured your app, even explaining to users that they need to clear their cache could be difficult...

You really need to plan ahead carefully if you're using the appcache, which I think changes the definition from "a nice tool, with some quirks" to "a complicated feature that you have to understand completely before implementing."

With that in mind, I think bootup.js is an interesting alternative if you can work around its other deficiencies.

I think you can classify lottery tickets as investment, wheras insurance is, well, insurance. I don't play the lottery because it's extremely unlikely to make me positive returns. I pay for health insurance because I want to cover the unlikely possibility that I have a serious health problem.

There's also the amortization to consider. Over a lifetime I may lose 50% of what I put in to insurance -- but I don't have 50% of what I'd put into it over my lifetime available to me now if I have a large medical bill to pay.