Likewise, got my wife on iOS to sign up, but shame I can't use it on Android yet. Hoping you can launch it there too soon, I really think this could be fun! Great take on picture messaging.
> I see more people driving break the law every day while driving then I've ever seen bikers do in my entire life. People are jerks regardless of what they use to commute with.
I don't think he (or many) would claim otherwise. The issue isn't the people who ride bikes, but rather the mode they choose to travel with and the impact it has on your drive. Bikers cause all sorts of added danger to both themselves, and you as a driver.
If you have a moment of human error in car-v-car, you're very likely to have both parties walk away from the incident. You call your insurance(s), your rates go up a bit, and your life moves on. Accidents are very, very common.
Repeat this same scenario in car-v-biker, and the odds quickly swing towards it being a life endangering accident. It's just a step away from hitting a pedestrian.
I don't dislike bikers because they slow me down or anything like that. I dislike them because of the likely increase in severity for almost all car-v-biker accidents.
edit: Interesting, seems i am getting downvotes for my opinion. Care to explain your thoughts? I can't imagine you (downvoters) feel that car-v-biker is an equal risk compared to car-v-car, do you?
Then you should be in favor of increasing biking infrastructure so that you're much less likely to make a mistake involving a bicyclist. But all the things you've said are equally true about pedestrians, which is a more dangerous, per-mile-travelled, mode of transportation than biking. And bike lanes in NY make pedestrians safer, too.
As a driver, it is your responsibility to manage a two-thousand-pound weapon responsibly. As you have the most power to cause harm, you also have the most responsibility to prevent it. The biggest problem with vehicles in the US is that you're "entitled" to drive without learning how dangerous you are to everyone around you, and how to navigate that danger safely. And when a motorists causes a fatal "accident" (due to texting, medical conditions, etc.), they are almost never at fault, and their driving privilege is rarely revoked. http://www.nytimes.com/2013/11/10/opinion/sunday/is-it-ok-to...
> Then you should be in favor of increasing biking infrastructure so that you're much less likely to make a mistake involving a bicyclist.
Of course i am. Not sure what made anyone think i'm not in favor of it.
Guess opinions are bad-form around this place :P
> As a driver, it is your responsibility to manage a two-thousand-pound weapon responsibly. As you have the most power to cause harm, you also have the most responsibility to prevent it. The biggest problem with vehicles in the US is that you're "entitled" to drive without learning how dangerous you are to everyone around you, and how to navigate that danger safely.
You seem to think my post was entitled, it's not. It's my opinion that i don't like them. I also do not like pedestrians jaywalking, but that doesn't mean i'm entitled. I would prefer to reduce risk by means that this article lays out.
I don't like things that increase risk. Bikers in my lane, infront of my "two-thousand-pound weapon" simply increase risk. It's like gun safety. I don't put my finger on the trigger until i'm ready to fire.
You (and i assume the downvoters?) seem to think that just because i express my opinion, that i would attempt to ban bikers from the roads completely. Far from it.
America is the only place in the world where jaywalking is a crime. The notion there is a correct route between two points is rather bizarre. http://en.wikipedia.org/wiki/Jaywalking
> Jay-walking is an offense. One may cross only at recognized crossing points if there is one within 100m. If caught by the police, the typical punishment is a
> fine.[citation needed] The same applies to crossing at a red light.
> Kosovo
> It is illegal to cross the road where there are no proper pedestrian signals or signs, resulting in fines of up to 20 Euros.
Furthermore, just because jaywalking itself is not illegal does not imply that pedestrians receive right of way to cross anywhere.
Various car related taxes and levies dont even begin to finanace the cost of road building and maintainance. Most of that comes from VAT and income tax.
Right. I don't get it. Bikers put themselves out in purposely dangerous environments and then are mystified and upset when they get hurt and angry at the environment they chose to ride in. I have absolutely zero patience for that kind of idiotic selfishness.
If somebody wants to ride a bike and wants to lobby for better bike riding infrastructure, I will be right there with them, even if it raises my taxes.
Yea, i really thought that this stuff should be out of dockerland. Not that i dislike the feature, just that it seems to overlap with established tools that excel at doing one thing well.
FWIW, now that docker is handling the restart/monitoring it can actually do it better than if systemd is doing it, since docker knows that it doesn't have to tear down and re-create the network namespace, unmount/remount the container's FS, etc.
So when a container is restarted via the restart policy, it not only happens faster, it will get the same IP as well.
It's something i've been struggling with quite a bit. Conceptually i love Polymer, and really want to switch, but React's serverside rendering is just hard to beat. I'm scared of showing users page load spinners while my 20 Polymer components all load their data heh
Facebook has been using React in production since 2011. Polymer is a "developer preview", aside from the Material Design presentation, I haven't heard of anything public-facing that Google's actually done with it yet.
React is backwards compatible to IE8. Polymer? Not so much. Unless you live in that mythical world of evergreen browsers, Polymer is sort of just a really great demo.
I haven't worked at a place that has cared about IE since 2009. Besides old versions of IE Polymer works everywhere. Worrying about being backwards compatible with old browsers is a thing of the past with constant updates to Chrome and Firefox. If you're developing a mobile site you can't use any of the newest things until Safari updates (about once a year, seriously) but you should be otherwise ok.
I work at a site where about 20% of traffic comes from IE8. Many are users on corporate machines with no alternatives. I really appreciate that React runs on older browsers and is decently performant without a huge payload. All this with a well designed API and a nice development experience... I think it's hard to beat!
Anyway the more traffic your site gets, the harder it becomes to ignore certain cohorts.
But Polymer depends, for example, on Shadow DOM, which is currently only supported by Chrome, Opera (Chrome-based) and Android browser - not even by Firefox yet (http://caniuse.com/#search=shadow%20dom). There are pollyfills but they're too slow to treat them as a viable solution.
In my experience, React has been a better realization of the concept behind Polymer ("reusable web components"), without the non-sense. I don't even consider server-side rendering the killer feature.
Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps, which is like wanting steak but eating liver.
I too struggle with the choice. Polymer/web components _might_ be an easier sell to my boss as it doesn't require as much framework specific knowledge and would make it easier to get new teammates up and running.
However, the polyfills + ammount of http requests in a very modular project don't inspire the confidence that Polymer is ready for prime time.
My thought is that when web components lands in browsers natively, and if some of the request problems are smoothed over, it would be easier to translate a react project than a project in another framework. You could replace things piecemeal. But by then, who knows how much more compelling react might be.
What I gathered is that Polymer, at this time, is simply not ready or even intended for production use; it's an experimental technology aimed to implement the Web Components standard, which at this time is still heavily under development. Polymer is aiming at the future, and as such will only become usable in the future.
It's also not intended to support older browsers; I'm okay with that.
Well, as unhelpful as this.. I love everything about Polymer, except the possible HTTP request spam and lack of serverside rendering.
Polymer is sort of React Components "To the extreme" (to me). They represent everything i love about React Components, with encapsulated JS, CSS, and HTML. Meaning that i can pull in someone elses Polymer component, or use one from another project, and it "just works".
Granted, the HTTP spam scares the hell out of me. Vulcanize may help with that, but i have yet to really figure out the whole process for my workflows.
Having to load an html wrapper, do clientside routing, load the data into the clientside templates and render templates all for the first page load just scares me with Polymer. React solves this by letting me do it all serverside, and it is wonderful at that.
I really do love React. I'll likely stick with React for another project or two, unless i conceptually have an "ah hah" moment with Polymer.. but until i can render Polymer serverside, i'll always be longing for React.
edit: Come to think of it.. If someone could bake html imports and shadow dom into React, i may be in heaven.
React already can render into shadow roots, and eventually we could add a mode that tosses aside server rendering in favor of shadow DOM. However, if all you want is style encapsulation, you can get that with conventions.
I'm not terribly experienced with React, but from briefly using it, I definitely prefer polymer's simple vanilla html+js declarative data-binding approach over react's JSX + element injection, from a basic usage perspective.
I think they solve two different problems. Polymer I see as useful for creating atomic UI elements while React.js is better for stringing the UI elements together into a cohesive experience.
Not to mention, that react side-steps the entire issue of heavy DOM reflows/rerendering as individual components update. I don't see Polymer doing anything but make that issue worse until browsers support it natively, and even then it will take some changes to the way browsers handle rendering to improve performance there.
I do think that long-term (5+ years) something like Polymer will become the preferred solution. For now, imho, React is about as good as it gets for componentized web applications.
I disagree; I think the weakest part of React is the lack of a true controller mechanism.
Everything is a view, even components that are structural more than visual. You achieve an MVC-like separation by designating some components as being owners of data, but it feels awkward.
Facebook's Flux looks like it may be a good solution, but I haven't tried it out yet. At any rate it is more about data flow than high-level application orchestration.
Fwiw, i use serverside React rendering with a Golang API server. My JS code has an interface layer which interfaces to browser/node, and on first load a balancer throws the request to Node, which makes local API calls to the api server, and renders it all in node.
Technically i use Node, but only to implement a small interface layer for things like http requests. So i don't really consider it a Node app. The real code is all React and Golang.
Awesome stack. It's exactly what I've started working on lately. I have 2 questions for you :)
1. What router do you use for react as it's necessary if you want multiple entry points into your app ? Rrouter seems promising.
2. How do you elegantly proxy client cookies from your node app to your api ? (both way: read and writes)
Thx!
I would want to rotate simply to get more resolution.. but then i'd wonder why i wasn't using the highest resolution from the start.. and then bam, i'm back to using the a normal camera app and holding it sidebars haha.
Though, i think i'd prefer this style app if it just picked portrait or landscape, and adjusted between just those two states dynamically. That would be nice if you accidentally shoot in one, and decided you wanted the other. Which happens quite frequently for me.
I'm quite happy to see this, from a Google Music user perspective.
I was getting quite antsy with the lack of music related features. Google Music was feeling so.. lacking. I was close to switching back to Spotify, or trying something new.
Glad to see something is still being worked on heh
