krschultz

Right but lets say I search for an old topic (not current news). It won't be on the home page of the WSJ, NYTimes, or WaPo. But I'd like Google to surface that for me since I'm a subscriber and pay to have access to journalism like that.

Different content to some search users. All WSJ subscribers see the same thing as the Googlebot.

But many Google users do see the content. I wish Google knew that I paid for subscriptions to WaPo, WSJ, & NYT and ranked things accordingly. I never want to open an ad supported story when the same thing is covered by a publisher I subscribe to.

Check out Litho, it's built around the principles of declarative APIs and one way data flow with immutable props. Definitely taking inspiration from React.

The key thing is that on mobile you are stuck with what the platform owners allow. On Android that's pretty much the JVM. You can get away with some things in native code (C, C++, now Go?), but most of the Android framework lives in the Java layer. Kotlin is pretty much your only option other than Java that works. The other JVM languages (Clojure, Scala, Groovy, etc) are quite a bit heavier and that's still an issue on mobile.

Jigsaw was started by Sun before Oracle even involved in Java. I know because supporting Jigsaw was on my radar - in 2008. I don't know where you are getting this conspiracy theory that Jigsaw is sinister move by Oracle. It's going to solve some of the worst aspects of the JVM (startup time, distribution). The reason it has taken so long is because it is technically difficult and there was a 2-3 year stall in JVM progress after Oracle's acquisition of Sun.

It's certainly cleaner as mentioned in the other comment.

Another factor is that natural gas turbines can be turned on and off more quickly than coal fired plants. This is because a gas turbine is literally burning the gas in the turbine, it's akin to a jet engine on an airplane you can throttle up and down. A coal fired power plant is really a boiler that creates steam, and then the steam is fed through a turbine. Heating up all the water to make steam actually takes a long time.

In an era of renewable energy sources (solar, wind) that fluctuate more unpredictably, having that "dispatchability" is really valuable.

http://www.nrel.gov/docs/fy12osti/55433.pdf

They're different. For starters, React Native developers are writing JavaScript. Litho is a Java framework. The primary benefit of Litho is performance, whereas React Native is focused on developer speed.

There's a reasonable set of language specific libraries listed here: http://graphql.org/code/

Also a common pattern is wrapping an existing REST API with a GraphQL proxy: https://github.com/graphql/graphql-js

Re-read The Innovators Dilemma. Startups built on just having better technology or product rarely ever work. You need to compete on an axis that the incumbent can't compete on. The incumbent should be looking at your startup, be aware of what you are doing, and be unable to copy it because doing so would break their existing (profitable) business.

If you are relying on outcompeting the incumbent directly you are in for a really tough fight.

Easier to optimize than what? I used to work on manufacturing nuclear submarines. We built exactly 1 of many things. You'd think that would mean there was no repetition, but that's not the case. The processes are repetitive, even if the product is not. Everything can and should be optimized, that's the only pathway to higher productivity.

Take it. I worked in a job like that, the emergencies are few & far in-between. When there is one, there are probably multiple people on the team that can handle it.

My group used to have a list to sign up for going out on sea trials. I never got high enough on it to go. If you don't want to go, I doubt you would have to.

If you are a startup and are trying to compete head to head with Google / FB / Amazon / Apple / Microsoft for the same people, you are going to have a really hard time recruiting.

But there are plenty of great engineers that don't want to work at those companies for various reasons. There are plenty of great engineers that want to work remotely and don't have that option at the large companies. There are also plenty of inexperienced engineers with high potential that can't yet get hired at those companies and can be great additions to your startup. Do what you can to find and recruit those people.

I did. I'm not sure if there is any features of value, but I pay for all the small apps I use so that the developers don't go out of business.

Apple should license a single boutique manufacturer to make high quality workstations. It's clearly not a big enough market to interest Apple, but with the right agreement in place they could come up with a satisfactory solution.

Signed

- A Mac Pro owner that is seriously considering getting something else.

I think this is preferable. If everyone was more upfront with their bias, then it becomes incumbent on the reader to get a complete view. Sure, plenty of people would just read what they want, but that's ALREADY happening. At least there would be less denial about it.

This going way over the line for politics on HN but I can't let it go. Everyone repeating the story you are pushing is robbing the Hillary supporters of their agency. I've voted for Democrats for years and years. I didn't view Bernie as a once in a lifetime opportunity. I saw him as way too far left for me.

I was clearly wrong on the relative electability of Hillary & Bernie, but I'm voted in the primary for the candidate that better represented my views. I didn't vote for Hillary because the DNC made me do it or the media lied to me. I watched their speeches, I read their websites, I watched the debates, and I decided I'd rather have Hillary than Bernie. That's it.

It's not a giant conspiracy, there's just a lot of rank and file Democratic voters that aren't all in on Bernie's worldview. If you want to make an argument for why I should be more in on the Bernie plan than Hillary's plan I'd hear it (I guess not on HN), but stop pretending like the majority of Democratic primary voters were duped.

You still incur a startup penalty with multi-dex, it takes noticeably longer than a single dex, even if you are only marginally into that 2nd dex.

N00b question, is this tech only on the Model S or is it available on all of the Teslas?

The history of self driving cars shows that it is not an easy task. We've been working on this for over 15 years. I was on a self driving car team during 2008-2010. We won multiple intercollegiate competitions. At that time I was certain it would be 20+ years before we had something that could drive on the roads. The progress has been spectacular.

s/lost/sold/

Twitter clearly decided that dev tools were a non-core part of their business. Meanwhile Google has been investing more heavily in becoming a platform company to compete with AWS, and also increasing their investment in mobile through Firebase.

I didn't love this book, it was OK. It's heavily based off The Goal, and I thought that book was a bit better. I think if you have a certain dysfunction in your team AND the mandate to fix it, then The Phoenix Project is a must read. For everyone else it's kind of a waste.

Our agency is collapsing. I recently read the Federalist papers. What struck me most was the impression that the founders viewed government simply as a problem to be solved. We view the Constitution as second only to God's word handed down on stone tablets, but it was just a bunch of guys getting together thinking through the potential implications of different systems. I'm reminded of the part of Zero to One that talks about how we used to imagine large scale projects (e.g. filling in the SF Bay, for better or worse), but today we barely can get 2 miles of subway built in NYC.

Somewhere along the way we fell into stasis. We have a bunch of a problems in society and in the world. They need to be solved. These days the only two dynamic areas are philanthropy and startups. Almost everything else - US federal, state, and local government, large legacy businesses, small businesses, the UN, the EU, NGOs - are stagnant.

Bandwidth & latency are different things. It doesn't matter how fat you make the pipe, the speed of light prevents certain types of computations from being run remotely.

This doesn't matter so much for AI in apps, but certainly for self driving cars all critical computation needs to be on the edge. Once you have every car carrying multiple GPUs, the distributed computing power in cars probably is pretty comparable to a data center. You can run a lot of things in the idle time while the car is parked if you need to do training or things of that nature.

Boiling it down to the core point, "the Bolt will let GM sell more swanky Silverado pickups at much fatter margins without paying penalties or buying credits from competitors".

It's important to know that fuel mileage regulations are calculated on a fleet basis, not per model. So manufacturers are actually trading off optimizations across their entire product line. The Bolt is just an iteration on the existing strategy of using cheap small cars to offset the emissions from larger (higher margin) trucks.

The apps don't really matter. I was the Android lead at Gilt and we often talked about open sourcing our app. We ended up open sourcing our iOS one (https://github.com/gilt/cleanroom). We were a company with a thousand employees, most of them not writing code. If you wanted to compete with us, copying our app was 5% of the overall effort, and what would you really get from our app that connects to our (closed source) backend anyway? The upside was enormous in terms of recruiting, retention, and keeping engineers excited.

Kickstarter is in an even better position. Their defendable advantage is the network effect of being the go-to place for crowd sourcing.

This is very exciting. There simply aren't a lot of open source "full scale" Android apps. Most of what you find are quick sample apps which simply don't show the complexity inherent in most professional apps. The largest other ones I'm aware of are Github, Google I/O, and some of the AOSP apps.

I gave a talk about this recently [1]. One of the subtle points of why GraphQL has the potential to be more productive for smaller teams & projects is because it is well specified. Standards are a bit constraining, but they're also enabling. There are already some nice tools built on top of GraphQL and more will come as the project matures. This is of course the same value proposition as Swagger, JSON-API, and other formalizations of REST. In my opinion those projects are likely more mature today - especially for native mobile apps. But in a few years? I suspect GraphQL will be more productive even for small teams.

[1] https://www.youtube.com/watch?v=P0uJHI7GjIc

I just go really high level. Larger companies usually have a process, sometimes it is categorized under "conflicts of interest". My current side projects are non-commercial, so I just put together a 3 sentence description of the project & a link to the GitHub page. Generally if the lawyers have any questions then I answer those, but I don't go overboard providing info. In the end it's better for everyone to have clarity.

"Don't even tell your employer about side projects. Leave them out of the loop entirely."

Early in my career I did this. Now I go the exact opposite tack. Tell your employer. Get it cleared in writing. If you work at a company where that is a problem, then consider your side projects non-commercial for perpetuity, or get a new job.