psgibbs

tl;dr: government incentives

Range goes way up – electrification can turn a 10+ mile commute from something intense (where you need a shower when you arrive) into something manageable.

It allows bikes to be a substitute for far more things that you'd otherwise use a different mode of transportation for.

My understanding is this is precisely backwards: using BMI to gauge your own health is inaccurate, but using it to analyze populations is the intended purpose.

I think there's some "both sides are equal" aspects in your position that mischaracterize the reality as I understand it.

In 2016 Democrats thought manipulation / fake news (exactly the root problem in this article) was happening, and it appears it was. They recognized there is risk to systems and proposed to enhance election security based on the new (and proven) information that state actors were directly involved in trying to manipulate our election. I do not remember (I may be proven wrong), Democrats undermining the fidelity of the election itself, or alleging fraudulent votes, excepting one or two places where it was proven to happen (see the Dan McCready campaign).

My understanding is both parties now are roughly aligned with their longstanding positions in terms of how they view election security and relative occurrence of voter fraud and malfeasance. Comparing the 2016 positions on interference via fake news is apples and oranges, it is fundamentally a different subject – and the allegations of election interference were literally proven true by a justice system run by the Republican party.

I've seen plenty of junior engineers who read a FP blog post, and start arguing about 'purity' and the need to refactor lots of code – without having any clue that pure functions are useful regardless of other coding paradigms / architectural decisions.

Without much more detail than this, they don't sound like cofounders. If they're waiting until you launch to go 100%, then you're assuming all the risk right now.

Again take with a grain of salt, bc I have no context, but , if there's one you think is clearly the best, that you like working with them, get them to be a cofounder and make them go all in. They can do lots of manual work to validate the idea/product (ie manually do things you'd like your product to do). If there's noone you could see doing this, then their role is probably not going to grow that much when there is a 'product'.

Also: the product will never be done, and framing launch as a binary event doesn't help you (or your potential cofounders). It's all just a continuous spectrum of trying to cover as much scope/utility as possible for your users, and using a product to try to automate that. After 7 years, you'd be shocked how much stuff my sales cofounder does manually that we had framed as a 'required feature for launch'.

I'd make the argument that because there are low costs of switching (as has been mentioned elsewhere), these are scale effects (like in most industries), rather than network effects.

Why? I actually still have a 6S and I find the physical button feels mushy in comparison to the new solid state / haptic button. Is there a disadvantage I'm missing?

Yes – every day. By most metrics, my startup is going great, but it's taken years of all-nighters, working weekends, and skipped vacations. I love what I'm doing, but I'm also cognizant of all the friends, relationships, family-time, and other experiences I'm not investing my time in as much as I should.

Whether things work out or not, I'll always wonder what the counterfactual was, all the unknown-unknowns I chose to miss out on.

Regardless of what you read, what you feel like you're missing out on, know everything comes with a sacrifice. My only advice would be to think carefully about what you choose to invest your time in.

Folsom Labs, San Francisco, Full Time Software Engineers (www.folsomlabs.com)

We make powerful design tools for Solar PV (think cloud-based AutoCAD with built in physics modeling). Our mission is to make these tools as easy to use as possible, which dramatically broadens the availability of solar. It's a unique place in the solar industry, new technologies desperately need software like ours to convince both banks and installers that they can have positive impact on energy production.

We launched to revenue in January, and have real traction and high growth, and we're still just a 4 person team, so there's a ton of opportunity. Everyday we get to deal with a range of problems that few startups get to offer – we have a modern web-stack, we need to use our cloud-clusters for the simulation half of the product, but also get to solve interesting physics/optimization problems on a regular basis (if that's your thing).

– Paul paul.gibbs@folsomlabs.com

[1] http://www.greentechmedia.com/articles/read/better-faster-ba.... [2] AngularJS, Python/Flask (API/Backend), Cython/C (Physics Simulation Engine)

We use it for our core app, and now have a bit over 10K lines of application code.

Our general strategy is to organize the app by functional areas, each area of which is organized similarly to how most angular sample projects are: with a directives.js, controllers.js, services.js, etc. We use ui-router to tie this all together.

It's a $10 million dollar idea, they just sold 15% of it.

The closest parallel I can come up with is Erlang, which (I believe) was developed by Ericsson specifically to handle their exchange traffic.

http://en.wikipedia.org/wiki/Erlang_(programming_language)

Folsom Labs, San Francisco, Full Time (www.folsomlabs.com)

Basically, if you are interested in science and/or energy, and want to do software engineering at a place that actually let's you leverage the math/physics you learned in college/grad school, we're probably as good a fit as you'll find. We make powerful design tools for Solar PV systems, making them very easy to use by leveraging a pretty sophisticated simulation engine (so we handle the physics for the user).

We've already launched our product[1], have some great traction (including a federal grant), and we're still just a 2 man team, so there's a lot of opportunity. Everyday we get to deal with a range of problems that few startups get to offer – we have a pretty modern web-stack [2] (that we actually need, not just to be trendy), but also get to solve interesting physics/optimization problems on a regular basis. It's a really unique place in both the solar industry, and as a software company.

– Paul paul.gibbs@folsomlabs.com

[1] http://www.greentechmedia.com/articles/read/better-faster-ba... [2] AngularJS, Python/Flask (API/Backend), Cython/C (Physics Simulation Engine)

I posted this on the "Who's hiring" thread a few days ago, but didn't get much traction. Basically, if you are interested in science and/or energy, we're going to be doing a lot of really interesting things spanning physics simulations, system optimizations, and, yes, 'cranking out web application features'.

We're literally two people right now, but have a great product, and great traction. It's not a traditional VC style market or exit opportunity, but our opportunity/headcount ratio is absolutely massive, and we desperately need to hire.

=======

Folsom Labs, San Francisco CA, Full-time Software Engineer http://www.folsomlabs.com

We're building the next generation in solar (PV) system design tools; basically we make it very easy to analyze the potential value of a new PV systems by leveraging an advanced physics simulation engine. We've been in beta for about a year, and are formally calling it 1.0 in a few weeks. We've got a lot of great traction, and almost universally stellar feedback from our users. We've also recently received a federal grant[1] to help fund our next generation of products (and a round of hires).

Everyday we get to deal with a range of problems that few startups get to offer – we have a pretty modern web-stack [2] (that we actually need, not just to be trendy), but also get to solve interesting physics/optimization problems on a regular basis, while also acting as industry thought-leaders. It's a really unique place in both the solar industry, and as a software company.

We've made it this far as a two-man team, and we're poised for a lot of growth in the next year, so it's about time we brought on some help. If you're a full-stack engineer looking to do some really interesting work (and occasionally put your undergrad physics courses to real use), we'd love to hear from you.

– Paul

paul.gibbs@folsomlabs.com

[1] http://www1.eere.energy.gov/solar/sunshot/incubator_projects....

[2] AngularJS (frontend), Python/Flask (API/Backend), Cython/C (Physics Simulation Engine)

*edit:reformatted the original "Who's Hiring" post

Folsom Labs, San Francisco CA, Full-time/Intern Software Engineer

http://www.folsomlabs.com

We're building the next generation in solar (PV) system design tools; basically we make it very easy to analyze the potential value of a new PV systems by leveraging an advanced physics simulation engine. We've been in beta for about a year, and are formally calling it 1.0 in a few weeks. We've got a lot of great traction, and almost universally stellar feedback from our users. We've also recently received a federal grant[1] to help fund our next generation of products (and a round of hires).

Everyday we get to deal with a range of problems that few startups get to offer – we have a pretty modern web-stack [2] (that we actually need, not just to be trendy), but also get to solve interesting physics/optimization problems on a regular basis, while also acting as industry thought-leaders. It's a really unique place in both the solar industry, and as a software company.

We've made it this far as a two-man team, and we're poised for a lot of growth in the next year, so it's about time we brought on some help. If you're a full-stack engineer looking to do some really interesting work (and occasionally put your undergrad physics courses to real use), we'd love to hear from you.

– Paul

paul.gibbs@folsomlabs.com

[1] http://www1.eere.energy.gov/solar/sunshot/incubator_projects...

[2] AngularJS (frontend), Python/Flask (API/Backend), Cython/C (Physics Simulation Engine)

It is, though if you're using PostGIS, I'd recommend GeoAlchemy2[1], which ties into SQLAlchemy a bit more naturally (because they get rid of support for all other engines). Also, seems to be more actively developed/maintained.

[1] https://geoalchemy-2.readthedocs.org/en/latest/

You can always create functions that refer to the private element:

MyObject.prototype.id = function(){return this._id;};

Which gives you: leagues/{{ league.id() }}

While I agree with this statement in general, it is a bit of a tautology - do cash reserves come from success, or cause it?

I agree that cash reserves help, but I think it's hard to ascertain how big a driver of success it is, given that it is also the result of success.

If you take a look at this video: http://www.youtube.com/watch?v=P6KITGRQujQ and associated tutorial, it will give you an example of binding to the RouteChange events for exactly this use case.

I don't get it, why are you afraid of scooping yourself?

In the same way that HN frowns upon stealth startups, shouldn't we frown upon 'stealth theories'? If your thoughts are novel and deep enough, revealing something about them will only increase interest in your future talks, since you are definitionally the foremost thinker in your unique worldview. If the idea fails scrutiny in some way, you should want to hear about it now so you can strengthen your position.

What's the downside, outside of using mystery to create artificial hype?

I'm not saying people aren't still choosing Backbone/variants today, just that 2 years ago, Angular was (1) not a nearly as viable an option and (2) not nearly as well known; so any time /company-size correlation will push the results in one direction.

edit: although interestingly, looking at the respective wikipedia entries, AngularJS has an initial release listed in 2009, Backbone.js is listed as October, 2010

I wouldn't draw a strong conclusion about 'larger' startups using Backbone instead of Angular based on this data.

There is probably some high correlation between a startup's size and age... Older startups are likely to be larger, and are likely to have started their stack using the popular framework of the time (Backbone). Newer startups will be smaller, and were founded at a time when new frameworks (e.g. Angular) are much more mature.

edit: grammar

If you don't have a specific reason not to, I'd highly recommend using the unstable branch today. I've had no problems with it since I switched several months ago, and any breaking changes have been pretty well documented in the release notes.

What this is missing is the amount of listeners each play counts for. On Pandora/Spotify/Youtube, a 'play' is typically one listener. For these, it's mainly worth noting that Spotify is about an order of magnitude more profitable per play ($1e-4 vs $1e-5).

Sirius is at ~$1/play, commercial radio is $0.07/play.

For Sirius XM, the breakeven number of listeners/play for the pricing structure to be comparable to Pandora is 70K. For Commercial Radio, the breakeven number of listeners/play is 5,000.

*edit: added the price/play numbers

Really, only in the sense that this source pushes out the aggregate supply curve, delaying the point in time when prices get higher.

Practically, once prices become 3x of current, that's what everyone will pay on average, it just means (in this thought experiment) that some miner sourcing from America is marginally profitable, while some miner from South America is very profitable.

I think typically people start them out in 'services.js' since effectively models in angular are constructors that are created, and then injected whenever you need a certain type (so you have a service that returns the constructor function).

A good example of this is how the tutorial treats the restful 'Phone' resource, creating a service that injects the resource where necessary. I've started calling them 'models' rather than 'services' internally as well, so it's interesting to me that others are too.

http://docs.angularjs.org/tutorial/step_11

I added 'evil' because particularly in this community, the connotation of 'hacker' is not necessarily negative. Many here esteem hackers as people who get things done by taking cleverly manipulating the system, or, alternatively, value results over process (I'd actually really appreciate a proper neutral definition of the term).

So all cops are 'agents of state violence'?

Just like all developers are 'evil hackers'.

If people realistically want the situation to get better, they need to embrace the 'good' police officers, rather than automatically ostracizing all police officers equally. Many still really do want to improve their communities.

I think there's a much simpler way to do fix it - force users to anonymously unendorse in such a way as to maintain a fixed ratio of endorsements to unendorsements. Don't show unendorsements or a negative endorsement level.

Suddenly incentives are much better aligned.