Inflection point: Kickstarter has 3 $1M+ project in 2 weeks - <AUTHOR> http://venturebeat.com/2012/02/20/kickstarter-million-project-pledge-order-of-the-stick/

<comment><USER2> Crowdfunding is a solution to high quality software development, open source development, science funding, and sopa/pipa. It's really quite amazing and people haven't caught on yet. It's also a solution to the startup problem of building what people want.

Eric Ries talks about "pre-testing" - put up a landing page and seeing if you get signups. However, this sounds scammy. A better way is to simply launch a kickstarter/indiegogo campaign. You release the software as open source, which is better for the world as well. But you also get paid as well. You want to launch as startup that does project management as a saas. Instead put a kickstarter campaign up for 1 million dollars, or however much you were expecting to earn from the lifetime of your startup. If enough people want it, it will get funded. The next step you build and release as open source. Afterwards you can host it, or a bunch of other people who are expert at sysadmin host it and get customers paying for saas. You move on to the next project you want to build. The point is, you can have many crowdfunding campaigns going. Think of 20 apps, list them for 60 days. The ones that get funded, you build.

It also solves sopa/pipa. Someone has ideas for movies, launches campaigns in parallel. The ones that get funded, he creates releases for free on youtube.

Same for science. Scientists would no longer need to be attached to a university or do the politics that is involved in getting funding in science. They go directly to the public.

In the above scenarios everyone wins. Customers and creators. The only people who lose are people who were good at politicking their way up the coroorate ladder. Although, they don't really lose. They can switch to being marketers who launch campaigns, however they'll now need to have competence in marketing and brainstorming ideas.

Firms only exist to solve the communication problem. Now that we have the internet, there really is no need for organizations to exist. As more database-based information systems are created for crowdsourcing (kickstarter, fiverr, mechanical turk) , the more efficient this process becomes - which is good news for startups because this is what they are creating.

<comment><USER3> With enough creativity Kickstarter can almost be seen as a marketing channel in addition to an early stage funding platform. Sounds to me like an ideal way to cajole friends and family into funding one's project/venture without having to formally raise a 'friends and family round', and without having to approach angel investors.

For no upfront marketing dollars you get free exposure, and the opportunity to reach prospects who - gasp - might even FUND your development efforts.

What a great way to reach, excite, delight and validate a market!

</comment></comment><comment><USER4> I run a magazine (<http://interestingtimesmagazine.net>) as a hobby. It could really use some funds. I've never really considered that we could raise money this way, but now I am getting more and more interested in taking that route.

Any tips would be most welcome :)

A good goal for us would be to get $2000/month (after taxes) which would go toward paying our graphic designer so that she doesn't have to work a full- time job. Is this completely unrealistic?

<comment><USER5> I could recommend retooling your mag for single landscape screens, but, a) I don't know your print:download ratio, and b) you asked about Kickstarter!

My knowledge does not come from using it, but instead trying to convince friends and associates to use it, after researching and being enthralled by the potential! First codes the news that, you can't use Kickstarter! Forever, you can use IndieGoGo, if you don't mind the higher total fees (7%, plus afee for not being American (money changing.))

Take inventory. What do you have that has value? Can you leverage that for backing? You're on issue #7 and don't charge, so offering free digital issues to low level backers didn't give you anything. But paper copies do. So any spare stock you have, well, consider this your "fire sale" to raise cash. If you print on demand... Ouch.

Make sure backers know this isn't business as usual, this is an event! I'd make the push to "back Interesting Times volume 2!" And start with new renumbering, and a quarterly schedule. This may be the time to start charging $2 a digital issue, and push to get into digital storefronts like Amazon, iTunes, and even Steam. Don't think this bad. I mean, if you can offer ~100 pages of content that's a great deal. And if not charge, which I understand, consider ads. (Actually, I personally other ads. But at that rate, I see no reason not to retool things as a website... And offering ads at reduced price could be great high tier backing options.) If you're okay with charging, consider subscriptions at reduced rates. Offer DRM free issues congruently with other pay options. But I'm getting into backing rewards now... As I said before, take stock. My point here really is, you want money to continue to chine in, right? Even after the fund raising?

Have people vouch for you. Any connections you've made, use. Ask people if they'd consider giving you blurbs. "Required reading for world domination. Or at least dominating your social circle." - Semi-Popular Person, Company/Culture X. This may play to the mainstream to give you credibility, but of course it also appeals to fans of that person's fans.

Find someone to help make you a worthwhile video. You have to know someone who can film and edit high quality video. If you don't, you can shoot it yourself on a cell phone, and use open source video editing equipment, all for nothing, but you have to make it "work." Get across not only yourself, but the idea that you're offering. Not "a magazine," but that after reading your magazine, your readers will be better equipped to succeed I the world around them. That, somehow, is your video.

And that video is probably the most important thing.

<comment><USER5> I guess one thing I was dancing around in this was said by someone else. If you don't find a way to turn this into a money making venture, you'll find yourself right back in this spot in a year. And if you do, you may not even need something like Kickstarter/IndieGoGo.

/edit: I also typed all of that on my phone. Wow at those typos. And how longwinded I got. By the I finished, I couldn't bring myself to editing on that tiny screen. Sorry about that. Feel free to ask or email if anything was too confusing.

Of course, that said, you can find all the same material I've read with a little Googling, I'm sure.

<comment><USER4> Wow, quality advice. Maybe I should contact you, eh? :)

</comment></comment></comment></comment><comment><USER6> What I find most impressive about Kickstarter is that they are becoming more of a marketplace with every passing day. In the beginning, it was mostly a tool to help project owners collect donations from close friends and family - and their immediate friends. That is changing by the day and witnessing the transformation is very exciting.

<comment><USER2> There are over 300 sites similar to kickstarter now. Competition will drive down the 5% fee kickstarter gets, and sites will start competing by providing api's for managing multiple campaigns, as well as differentiating on providing marketing support.

This is a great opporunity for startups - both getting funded on crowdfunded sites and launching crowdfunded sites, because unlike the usual ad-supported business model or saas offering, serious money changes hands and every sector of the economy can be flowing through this.

<comment><USER7> In 2 sided markets network effects can keep margins high since going to one of the 300 kick starter competitors may mean not getting your project funded.

I doubt their fee will go down ever.

<comment><USER2> There isn't a network effect in kickstarter. Whether you get funded is basically up to your social media campaign. Unlike ebay, you cannot be anonymously selling your wares with your seller score being your reputation. In crowdfunding you have to go all out - you already need a solid track record that is publicly visible. Funders are basically doing a due diligence check on you. You need a profile on many different sites and email newsletters etc. Crowdfunding sites are basically an reverse bounty system - a kind of api for gathering and dispensing money. The only differentiation between indiegogo and kickstarter at this point is the percentage they keep.

As regards ebay, their network effect hasn't worked out - amazon has taken their business. In the future Amazon or Google might come in take out all the crowdfunding sites by offering a reverse bounty api. At that point, the crowdfunding sites should move in to the function of providing marketing services for creators seeking funding.

<comment><USER7> I don't agree with you for many reasons:

1) Creating an account and entering banking numbers etc. is a real friction which is not easy to overcome.

2) People can go on Kickstarter and see a number of projects which they can fund without any prior knowledge of the person they are funding.

3) eBay is a $45B business which almost all of the value comes from network effects. Sure, Amazon is doing great (80B+) and is taking some of their business, but eBay is still a cash machine.

4) Looking at Indigogo it says that if you raise the money the fee is 4%. If you don't raise your goal the fee is 9%. While the 4% is better than 5%, my guess is that the total expected fee is actually above 5%.

6) Crowdfunding is not as simplistic as it appears on the surface. While not having the funding as an investment gets around many of the issues associated with the Securities and Exchange Commission, making a mistake could land an owner in jail or with substantial fines. Even if the owner did not mean to make something sound like an investment, if they do, it is a huge penalty. A simply API to create many more reverse crowd funded sites would not work out well on the average.

</comment></comment></comment></comment></comment><comment><USER8> Question: Why aren't kickstarter backers required to be accredited investors? I ran into that problem trying to join SecondMarket. How is the kickstarter model different?

<comment><USER9> I don't know of any kickstarter that has offered equity.

I think the reason you do not need to be an accredited investor is that: they are not investments.

<comment><USER10> Doesn't the success of Kickstarter mean we need to rethink investment laws? I imagine this sort of businesses, where they help start-ups get funding, would explode if people could get equity in the companies. The equity per investor could stay small, so random people don't have much of a say in how the start- up is run.

<comment><USER11> Kickstarter hasn't really faced many scammers yet, but as it becomes more successful more people will propose projects that they dont intend on fulfilling (and pocketing the money).

<comment><USER12> This is what I'm interested in understanding.

Right now kick starter and many other sites are handling scammers because, there aren't that many.

What happens when they do try to abuse the sites though?

</comment></comment></comment></comment></comment><comment><USER13> At what point does Kickstarter become a NGO stand-in for the more traditional Gov't grants that are continually being short-changed in budget battles and austerity measures?

It will also be interesting to see how a move to "crowd-sourced" changes what pursuits are successful. Presumably, the upside to something like Kickstarter (as opposed to tax-funded Gov't grants) is that the individual financiers have a greater say in what they value enough to fund. The downside, I worry, is that some of the best things to come from science and technology in the last century would probably never have gotten funded...

Also, it bears mention, while $1M+ is a lot for an indy game developer or starving artist, a basic biomedical research lab needs at least that much _per year_ and the standard amount for an R01 grant from the NIH is ~$4M for a 2-3 yr project.

</comment><comment><USER14> Consider that people were saying Louis CK was a chump to spend so much on the website he had made to sell his video. That was $32k. These mega-Kickstarter projects are giving Kickstarter at least $50k (5%).

<comment><USER15> Some of the big differences are that A) You only pay Kickstarter that 5% ($50k+ for a mega-success) if you're funded so you're reducing your risk (Tim Schafer honestly seemed to be aware of the possibility that he wouldn't be able raise the requested amount) and B) Kickstarter offers some degree of discovery and promotion (not so much that you can throw a project on there and walk away expecting people to just find it, of course, but a project like Pixel Sand[1] likely only got funded because it was on Kickstarter [also it benefited from serendipitous timing]).

Louis CK had reasons to expect his project would be successful and widely promoted and so increasing his up-front expenditures instead of going with a Kickstarter makes sense in his case (setting aside whether he could have gotten the same custom-built website for less cash).

[1] [http://www.androidrundown.com/blog/kickstarter-spotlight- pix...](http://www.androidrundown.com/blog/kickstarter-spotlight-pixel-sand/)

</comment></comment><comment><USER16> I don't understand why they would want to keep business's off of kickstarter. It seems there is a real opportunity to provide this service for small business's.

<comment><USER17> The reason kickstarter projects are interesting and worth the several-months wait for the rewards is that it's enabling unique projects which you wouldn't get any other way. If it got overrun by businesses using it as a pre-order catalog, it could lose a lot of appeal and end up competing with traditional web catalogs like Amazon.

<comment><USER16> I bet that there are lots of companies that have interesting project ideas but not enough resources to bring them to market. Do you really think it would become a pre order catalog? I think letting business's get information about what people wanted ahead of time would increase the quality of projects/products being created.

</comment></comment></comment><comment><USER18> Let me get this straight: can you fund a startup with Kickstarter or not?

I used to think yes but the in the interview someone from their team (?) says no.</comment>


Knowledge workers are bad at working – and what to do about it - <AUTHOR> http://calnewport.com/blog/2012/11/21/knowledge-workers-are-bad-at-working-and-heres-what-to-do-about-it/ <comment><USER2> As a programmer, one of the most effective forms of deliberate practice I've ever experienced is to write a complicated piece of software, and then _completely re-write it from scratch with a different approach (and then do it again)_.

Of course, that almost never flies in the business world. They'll ask you why on Earth the company should pay to build something _again_ before they make money from it. However, it truly is a powerful engineering process for many types of problems.

The point is not to merely rebuild it for arbitrary reasons. Rather, to take stock of the benefits and the pain that arises from the current design, and to try completely different approaches. You do it because there's a nagging voice in the back of your head that tells you that you've left some "goodness" on the table ... that even though your current implementation "works", the problem could be solved better.

You've already "loaded the problem into your head," because you've solved it once. The second solution will improve in some ways and possibly regress in some ways. Often, the 3rd or 4th solution will be "right" -- which means, not perfect, but significantly better than your earlier approaches.

It seems kind of like learning the card game of Bridge by playing the same hand over and over to see if you can get it better. Or learning chess by starting from the same canned starting position and seeing if you can play it to completion better.

<comment><USER3> That's actually a fairly well-known thing. Look for "Second System Effect" (See "Mythical Man Month").

Basically, v1 sort of gets the features working, but has lots of work-arounds. v2 is trying to solve all the issues you got wrong in v1, and wants to be the most beautifully architected solution.

As a result, it's almost always completely over-engineered and in danger of collapsing under its own feature weight.

v3 is the one that gets it right.

<comment><USER2> I have heard of that (and also, unfortunately, experienced it), but that is not what I was talking about.

The second-system effect is a product of naiveté. I've made that mistake more than once, but I believe I know better than it now.

But this practice of rebuilding from scratch I'm describing is not that. It is more a matter of practicing craftsmanship.

It's like a sculptor who sculpts a wolf, sees its good and bad, then gets the exact same size block of wood and sculpts it again -- but differently. And again. Not out of naiveté, but out of a patient determination to get better.

<comment><USER4> I used to do the exact same thing in Math classes. Iterate on proofs, until I got the perfect one. It vastly enhanced my understanding _and_ gave me these really pretty proofs to look at!

In one class where I was especially obsessed, my (rather famous in the field) professor told me I understood the subject better than he did. That was pretty awesome.

<comment><USER2> That is what I am talking about. Thank you for supplying another example that helps articulate it.

</comment></comment></comment></comment></comment><comment><USER5> Some context: Here Cal Newport is extending some of the ideas presented in his latest book "So Good They Can't Ignore You".

In the book he says (among other things) that _how_ you become 'so good that...' etc is by what he calls 'deliberate practice' - which in turn has two components -

(1) 'deep work', the doing of which actively stretches you while you are doing it (in term of guitar playing, this would be acquiring new rhythmic abilities, vs just playing/performing songs you already know). The 'practice' in deliberate practice should maximise 'deep work' (as per Newport)

(2) fast feedback loops - either by other (and ideally better than you) people, or built in (if you play a note wrong, you know instantly)

This blog entry and its neighbors seem to explore how he applies this philosophy to his chosen activity (research in CS). It is not entirely clear how to apply it to programming.

</comment><comment><USER6> > _In order to achieve consistent deep work, I usually need to first immerse > myself in the relevant research literature, seeking a problem that it is > recognized as important, unanswered, but probably answerable with my skill > set. This is not easy._

I want to run out and repeat this to every PhD student I've met in the last 2 years.

</comment><comment><USER7> The claim that knowledge workers spend all day answering email and do nothing to focus on self-improvement is just plain bullshit. The fact that we're presently using a website that essentially serves as a crowdsourced, real-time trade journal counters that argument. The existence and wild success of engineering-focused conferences counters that argument. The proliferation of easy-to-access information for professional growth allows for a self-selecting group of people to improve their lot in life just by picking up some new skills and getting some experience with them. You can learn a new skill literally by browsing the Internet these days. As such, I don't really view the knowledge worker as a person at risk of stagnation without actually making an effort to be lazy.

There are some people who feel that they already know everything they need to know, and don't want to better themselves. It is entirely attitudinal, and in no way unique to the "knowledge worker" classification. I would argue the problem is far more significant in other industries, such as manufacturing and other heavy industry. When a specific kind of job replaced by a machine, or an entire industry gets outsourced to another country, the individuals previously responsible for that kind of work are likely not to have been trained for any other function. That would probably be a better audience for this kind of thing, compared to people who spend their free time reading about new technologies and playing with them on the weekends for fun.

<comment><USER8> > You can learn a new skill literally by browsing the Internet these days

Nope, you can learn _of_ a new skill by browsing. And that's quintessentially shallow work.

I'd also point out that HN ( like the original reddit) was full of "hard" articles, that would take me hours to really understand and work through. While this kind of article still pops up occasionally here, its more common to just see easily digested blog posts now. I assume this is a normal consequence of HN's increased readership and regression to the mean.

The problem that this blog post addresses may be more generally applicable than the author thinks, but the existence of HN is hardly a counterexample.

</comment></comment><comment><USER9> On a related note, there is a very real risk in larger, more bureaucratic, organizations that it becomes easier to be recognized for shallow work than for deep work, managers like metrics and the shallow work is typically very much easier to quantify - leading to the Dilbert "I'm gonna right me a new mini-van" scenario - or whatever the social media equivalent is.

<comment><USER10> I get the sense that a lot of organizations go out of their way to make sure individuals are recognized for shallow work, because we know by experience it's less self-fulfilling for most of us (if not outright boring).

I still proudly keep the multimeter I won for "Tech of the Month" (I was the tech who accounted for the highest percentage of time in the time tracking system that month.)

</comment></comment><comment><USER11> I like the idea of making sure your tasks have a certain amount of "stretch" (i.e. push yourself a little with every task you give yourself).

We focus so much on our skill level that we forget that the "flow" state requires challenging yourself: [https://en.wikipedia.org/wiki/Flow_(psychology)#Conditions_f...](https://en.wikipedia.org/wiki/Flow_\(psychology\)#Conditions_for_flow)

</comment><comment><USER12> I agree with the OP. My day job is somewhat interesting but I have a feeling once I've figured out how it works that I'll be back in the same boat of doing less of my craft and more process. I am very lucky that in software engineering the body of knowledge is wide and always changing and that I genuinely like it.

At night I've become more accustomed to reading tech books on the newest technology instead of whatever book for book club. Our profession almost forces us to keep up or get left behind. I love it. Always gets me motivated to think and expand my knowledge.

</comment><comment><USER13> This is a great article, I can totally relate. I have been doing work that had not involved deep work for maybe a year, I kinda had plateaued my learning as a result of an unchallenging and demotivating work environment, I realised this is not what 'I' wanted to do, so I got out. I have hacker news to thank for this partly too.

4 months later I feel like a kid again my mind is like a sponge for knowledge, and because I have cleared my desk of non beneficial work, and as a result I have been learning at a fantastic rate.

Things I have been spending my team on include, functional programming techniques, JavaScript client architecture, pure REST api design, algorithms, visualisations in the browser (d3), geojson, node, mongo, redis, to name but a few

</comment><comment><USER14> I think this article is a great summary on how to improve your skills as a knowledge worker. I see people that believe their mental capabilities will never improve. It really comes down to step #3: the stretch. Many people skip over "the stretch" in all areas of life and reach "steady state" relatively early on.

</comment><comment><USER15> Please spare us this trite bullshit. I see people trying to justify their inability to improve themselves all the time. "If I'm having trouble, everyone else must be too!", they think, instead of considering the obvious: maybe they just suck.

There will _always_ be time-wasters and people who get off on bureaucracy. But I'm willing to bet many of us, especially here on HN, routinely get admonished for "forgetting" to do menial, time wasting tasks in favor of doing what we love. If you're wasting your time instead of taking every opportunity to learn you'll get no sympathy from me.

<comment><AUTHOR> _Please spare us this trite bullshit._

I posted it not because I agree with his assertion (I'm not sure I buy everything he's saying) but because I thought it would spark interesting discussion. Since "knowledge worker" is roughly synonymous with "white-collar office worker" (not necessarily programmer) I am inclined to agree with him.

 _I'm willing to bet many of us, especially here on HN, routinely get admonished for "forgetting" to do menial, time wasting tasks in favor of doing what we love._

Sure, we do. Most programmers and especially most white-collar workers don't. They waste their time instead because it's the more _comfortable_ way of dealing with management, which means they never improve and we have to clean up their messes and deal with their shitty code. It becomes everyone's problem.

<comment><USER15> I did not mean to direct that at you, but at the author. I agree that there are some interesting points in the article, but the pervading attitude in this article and others on the site is that you can use these methods as a substitute for real passion about what you do. I submit that going through such motions mechanically won't be easy because, after all, it's still "work." If you'd rather be doing email or browsing reddit, a disciplined method of self-study isn't going to help. Only if you're already passionate about what you do will you be able to consistently engage in the "deep thinking" the author talks about.

<comment><AUTHOR> One thing OP discusses in his self-help literature (which I haven't read, but I've heard it's pretty legit) is that rather than trying to rearrange their lives around finding some "passion", people should try to bring passion to their work. It's a counterbalance against the "do what you love and the money will follow" bullshit that has wrecked thousands, if not millions, of lives.

There's some sense in this. For example, when I was a teenager, I thought being a novelist or poet was what I wanted to do, and I had no idea that I'd ever find things like "machine learning" and "functional programming" interesting because I didn't even know what they were. I realized that the market signals were probably right in steering me along the mathematical direction, because (at least for this point in my life) I'm a better fit for the high-end CS and mathematics than I would be for the literary world.

All that said, there are definite limits to that approach. He's right that people need to be more flexible regarding what to be passionate about, but for a lot of jobs, there just is no way to become passionate without also becoming unemployable and insubordinate. What most self-help writers fail to grasp fully is that most people face inflexible, life-wrecking constraints and limitations that they're powerless to change.

<comment><USER4> _For a lot of jobs, there just is no way to become passionate without also becoming unemployable and insubordinate._

FYI, Cal actually covers this in his book-he has a very specific framework for figuring out if a career has a reasonable possibility of giving you the autonomy, competence, and freedom you need down the line.</comment></comment></comment></comment></comment>


Jim Sterne on Measuring Your Social Media Marketing Campaign - <AUTHOR> http://blog.mixpanel.com/expert-interview-series-jim-sterne-on-measuri

<comment><USER2> Shameless plug: <http://www.meteorsolutions.com> is a pretty cool product in this space. And we're hiring :D</comment>


Show HN: Product Hit – Industry pros tell you about best features for your app - <AUTHOR> http://www.producthit.io/

<comment><USER2> Seems like I need an invite to post. Any chance I could get an invite? @TheKaranGoel

<comment><USER3> I just logged in with twitter without an invite.

<comment><USER2> But I think you need one to post a question?

<comment> w0rd-driven Do you have the Add Question button in the top right? I haven't bothered trying to add anything because I don't really have a question yet. I got 2 invites for signing up too. Maybe your account got bugged if you can't say the same?</comment></comment></comment></comment>


How to Get 100/100 Google Page Speed Score with Middleman and Nginx - <AUTHOR> https://elliotec.com/how-to-get-100-google-page-speed-score/ <comment><USER2> Google Page Speed scores sometimes give bad advice that can actually slow down page load speed. I just focus on load time and the experience of the page loading. I sort of wish Google would kill the tool off or give it more context. Instead they just have a disclaimer at the bottom that says it's a recommendation and doesn't take into account experience...but try explaining that to a client. Any static site is going to load fast though, it's when you have to make database and API calls when things get hairy.

<comment><AUTHOR> Any examples of the bad advice that would slow down the page?

<comment><USER2> A very basic example: if you had a large site, you can raise my Google Page Speed score by inlining all CSS and JS, but that would be stupid because it doesn't take into account the next page load and caching. I've seen some render blocking optimizations slow the overall page too. Getting rid of query strings is nice, but sometimes you need it for cache busting and other things, but it penalizes your score. Even Google's own tag manager/analytics scripts lowers your page speed score when they are on the site.

<comment><USER3> >> Even Google's own tag manager/analytics scripts lowers your page speed score when they are on the site.

I never understood why Google doesn't fix this. I want to use Google Analytics but their own tool penalizes me for it because it gets unproperly cached on Google's own servers? That's just stupid.

<comment><USER4> It's just a tool with a random score - why does it matter? Most of the recommendations are now outdated. Focus on overall experience and there are plenty of RUM monitoring scripts you can use (that take advantage of the very fine grained performance timings available in browsers today).

</comment></comment></comment></comment></comment><comment><USER5> Some of those optimizations become irrelevant (or downright bad) with http2. Inlining CSS ans JS is no longer best practice when you can do a server push of those and avoid sending the extra bytes once the files have been cached by the browser.

Some optimizations can backfire. Adding async to the external JS is a great tip.. unless you have dependencies between your different scripts (i.e. you need one to be loaded before the other one gets executed)

<comment><USER6> That's something that really astounds me with this async thing.

Why on earth when they introduced it they didn't add a way to tell the browser the order of execution ? Or may be it exists and I haven't heard about it ?

<comment><USER7> There is a way: ES6 modules. If you can account for the order of execution (with modules or custom loaders) async is, in almost all cases, the best way to load your scripts. Defer (or body-end) scripts also specify the execution order, but only in a strictly linear fashion which usually has a performance hit.

</comment></comment></comment><comment><USER8> We love Middleman for static sites; curious why you chose to go with a server instead of S3+Cloudfront or Netlify. One of the biggest reasons we use static site generators is the ability to CDN the whole thing, making it dirt cheap and blazing fast.

<comment><USER9> > making it dirt cheap and blazing fast.

If you're using S3+CloudFront, it's not dirt cheap.

Traffic at AWS is so expensive, at any scale it's cheaper to roll your own. Significantly.

(For traffic in the EU, that is, in other regions traffic tends to be a lot more expensive)

<comment><USER10> For what you get out of the box with this setup (or Google Cloud Storage + Cloud Load Balancing/CDN) it actually can be "dirt cheap", depending on your business goals/traffic. Just like anything, it depends on what you value/what your time is worth. The pricing difference would need to be several (several) orders of magnitude larger than it is for me to worry about the few dollars a month I'm spending on each static site sitting in S3/Cloud Storage.

Also, if there is an issue with either of these it's far easier for me to justify downtime to a client by saying "Amazon us-east is down, here's Amazon's status page" then trying to explain who OVH is.

<comment><USER11> You will need to spend time to set up your site for Amazon or for cheap DO instance, I don't see what you can save here. You can have your own virtual server with root privileges and iptables and custom software and with Amazon you will have to pay for every new feature.

<comment><USER10> As I said, it really just comes down to business goals. Setting up a shared DO box with iptables isnt worth my time when it's still just a single DO box at the end of the day.

S3 + Cloudfront + ad hoc Lambdas is a far far easier cost benefit ratio when it comes out what my time is worth. To each their own :)

<comment><USER12> I'm under the impression that by "it's not worth of my time", you actually mean "I don't like sysadmin" :)

<comment><USER10> Ha. Well, it's more that there are things I can justify charging for and things I cannot. Standing up a sub par solution for a larger investment of time doesn't make a ton of fiscal sense to myself or my clients.

<comment><USER12> Yeah indeed, for contract customers, better go with something you're confident everybody will already know, since other people will have to manage it when you won't be there anymore.

In a previous startup I was CTO and founder for, I used a gentoo and managed everything possible by myself. This was not especially costly in time because I was already used to it and efficient, and we managed that way to stay for 3 years with 70€/mo in infrastructure cost. This has its advantages too :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> It is a shame that you dont get into details technically. The article now is basically the same as looking at the recommendations of google page speed itself.

<comment><AUTHOR> What level of detail are you looking for? I'm happy to expand on it.

<comment><USER13> Thanks for getting back to my comment. Reading back my comment I might have been a bit harsh, I am sorry about that. The level of detail in the compression and caching bits were very detailed, thanks for that.

What I was most interested in technically is the part about 'Prioritize visible content'. You talk about "loading third party scripts later, and generally keeping the above-the-fold content small and fast". From this I make out that you do not load images below the fold, etc. I was wondering what you do technically to make this happen. Also, how would you load fonts after the first paint, etc. Also, from what I remember, when you inline your CSS you make caching the CSS separately from the HTML impossible. What would you do when you want to have a quick first paint, but also want to leverage having CSS in its own file?

</comment></comment></comment><comment><USER14> One odd thing I bumped into is Google speed suggestion "complaining" about leveraging browser caching, but it reports Google Analytics as an offender :-/

        https://www.google-analytics.com/plugins/ua/linkid.js (60 minutes)
        https://www.google-analytics.com/analytics.js (2 hours)

<comment><USER15>
        location /analytics.js {
            proxy_pass https://www.google-analytics.com;
            expires 1d;
        }

<comment><USER11> You might serve an outdated file and lost a day worth of analytic records as a result.

<comment><USER15> Never seen that happen before - but you have a point assuming google implements a drastic change.

</comment></comment></comment></comment><comment><USER16> Has anyone else had trouble using pagespeed insights recently? I think they changed something about their API, every site I try to test gives me "The referrer [https://developers.google.com/](https://developers.google.com/) does not match the referrer restrictions configured on your API key. Please use the API Console to update your key restrictions."

Note I'm not actually trying to use the API, I just want to run the tool from [https://developers.google.com/speed/pagespeed/insights/](https://developers.google.com/speed/pagespeed/insights/)

</comment><comment><USER17> For Jekyll users, you can do just as well with CloudFlare and GitHub pages (all for 0$): [https://wiredcraft.com/blog/make-jekyll- fast/](https://wiredcraft.com/blog/make-jekyll-fast/)

</comment><comment><USER18> Note that you have to use a workaround to get 100/100 - it excludes Google Analytics when the analysis is running.

I always get pinged for GA and for Google Fonts. Not sure this makes any sense. Kind of detracts from the tool in general, actually.

<comment><USER19> But loading external fonts does take additional time. So to say, oh yeah, I have GA and fonts and I'm still 100 sounds disingenuous because it could still be faster.

Context is key. Nobody should be shooting for a perfect 100 in any situation where a barebones static HTML document won't suffice. So if you have to make DB calls to create the HTML document, or are reasonably delivering a nice user experience (e.g., a custom font), then you should not be scoring 100.

With that being said, you are still doing great for what you are delivering if it's non-static content with fonts and can get to at least 80 / 100.

<comment><USER18> Maybe so, but PageSpeed still gives you bad advice on it.

</comment></comment></comment><comment><USER20> I have recently built a tool to help me monitor Google Page Speed Score daily and notify me when it changes - [https://twitter.com/SocialMindAI/status/920979239226302464](https://twitter.com/SocialMindAI/status/920979239226302464)

Interesting thing is that the score fluctuates without me doing any changes.

</comment><comment><USER21> Plain [https://www.google.com](https://www.google.com) gets 79/100 but when you perform a search, it gets 98/100 ([https://encrypted.google.com/search?hl=en&q=test](https://encrypted.google.com/search?hl=en&q=test)) ...

</comment><comment><USER22> Who really cares scoring 100/100\. Is there a top 1000 site that is even in the low 90's? I love optimizing pages for speed but to claim 100/100 isn't going to achieve some magical jump in organic rankings either because of decreased page load speed.

<comment><USER23> People care when they have paid you to optimize their site but they only get a score 86/100.

Trying to explain the page speed tool is just a 'rough guide' and that a website always has to be some kind of compromise between speed, functionality and design falls on deaf ears because 'google' is, well, 'google'.

<comment><USER22> I agree but like everything with optimization and refactoring, the cost to move up towards a 100 offers less ROI in the end. I think if you're at 90 that's solid, no desire to be in the 100 club nor would I tell a client you need to be there.

<comment><USER24> 90 for mobile, desktop, both?

</comment></comment></comment></comment><comment><USER25> Did you try using Imgix for images? We did that this week and so far we like it a lot

<comment><USER8> We just started using Imgix on our most recent Middleman site as well and it's been great.

</comment></comment><comment><USER26> Does anybody know how much the actual load time factors into the "PageSpeed"? In my experience, you can have a site that loads quickly but gets a mediocre score because it violates Google's guidelines.

<comment><USER27> It really depends on the specific site. The gold standard is to open up the network tab of your browser's debugger to dig into the runPageSpeed API call that gets used behind the scenes. Specifically, dig down to .formattedResults.ruleResults and look at the ruleImpact of each category. It's not an exact correspondence to points taken off of a score out of 100, but it's roughly proportional. That is, if you have a rule with a ruleImpact of 20 and another of a ruleImpact of 10, fixing the ruleImpact of 20 will have twice as good of a positive effect on your overall score.

</comment></comment><comment><USER28> I tried gzipping my static site up front on maximal compression levels. Google the `gzip_static` directive.

It doesn't make a noticable difference, but it's fun.

<comment><USER29> what about Zopfli/brotli?

Gzip compression benefits taper off in benefit after the "7" setting, IIRC. Brotli at higher settings compresses better, but you'd want to do it static as opposed to on the fly (at higher/highest settings)

<comment><USER28> I've tried that as well, but you need a brotli module for nginx. No problem if you're using Docker, but I just used the mainline distribution of nginx on Ubuntu 16.

I'm curious if brotli's decompression is still fast on high compression levels. This is the case for gzip IIRC.

<comment><USER30> > _I 'm curious if brotli's decompression is still fast on high compression > levels. This is the case for gzip IIRC._

Yes, it's optimized for fast decompression. Compression, on the other hand, is comparatively expensive. This trade-off makes Brotli very interesting for static assets.

[https://quixdb.github.io/squash-benchmark/](https://quixdb.github.io/squash- benchmark/)

</comment></comment></comment></comment><comment><USER31> 404 for me on "Here's the link to my full Middleman config.rb"

</comment><comment><USER32> The link to your Middleman config is broken FYI

<comment><USER33> I'm also getting a 404 for the linked github repository.

OP thanks for the great article.

</comment></comment><comment><USER11> Google Page Speed is an awful tool. For example, it often advices to compress images and even suggests to download "optimally" compressed versions. Those images have awful quality, and have visible compression artifacts. The person who chose this level quality is probably blind.

Also it often gives crazy advices, for example something like "embed CSS code necessary to display the top of the page, right into the page". Not only it is difficult to implement, (what exactly is "the top of the page"? how to understand what part of the code is necessary? what if the user scrolls the page down while loading?), it will make the pages larger and doesn't allow browser to cache embedded CSS. So you have to invest a lot of time and your page will probably load slower as a result.

But at the same time this script doesn't notice obvious things. For example, it never advices to remove or replace web fonts although web fonts are heavy, can cause problems with rendering text (they can lack glyphs, for example cyrillic or CJK characters) and __web fonts block text rendering __. And they are really unnecessary in most cases because builtin system fonts usually look better at small sizes (at least on Windows).

Also it never advices to remove ads althogh ads often cause high CPU and memory consumption. Why is that I wonder.

The tool always requires to move JS scripts to the bottom of the page. But is it always the best idea? I think in most cases it is not. For example, if you have a button with an onclick handler, it will give a JS error if the button is clicked before the scripts in the bottom of the page have loaded (the problem of dead JS controls). And if you put a small JS script at the top of the page, there will be no error. And what if you have a SPA? In this case the earlier you start to load the scripts the sooner the user will be able to see the data.

Also it always recommends to use a CDN which is not always good idea. For example, if you have a site in Russia or China and move your static files to CDN then it might be farther from the user than your server and even worse, it can get blocked so your site won't even be loading. Adding a CDN often doesn't make performance any better but reduces the reliability and increases your hosting bill.

So Google's script might help you in identifying problems with your site but you should not ever blindly trust any of the recommendations. Please leave client side optimization to people who have expertise in this area.

By the way I had to lessen the image quality to get a better score (and foolow other useless or even harmful recommendations) because our management believes that the score given by this tool (it is Google's official tool after all) affects SEO rankings and obviously they are more important than image quality.

<comment><USER11> Also it recommends to "leverage browser caching". I.e. set unconditional caching of every static resource for a week. Please remember that it means you will have to implement a solution to reset the cache when you deploy new versions of static files. It might be quilte costly to implement correctly on a legacy site. By the way you can trick Google by enabling caching for a week and then appending current time to every link ([http://example.com/file.css?t=12:00:00](http://example.com/file.css?t=12:00:00)). In this case you will get a good score AND your users will always get the latest versions of the files.

The article says "Then, inline your CSS and JS instead of making external resource calls to them." and this is actually what makes your page heavier.

> Finally, I was having a lot of trouble getting the Google Analytics script > on my site to not be render-blocking

It is easy. Don't understand what was the trouble.</comment></comment>


AT&T preventing Time Warner shows from airing on Netflix - <AUTHOR> https://arstechnica.com/information-technology/2020/02/att-lost-1-2b-by-preventing-time-warner-shows-from-airing-on-netflix/ <comment><USER2> So why isn't it illegal and jailable for AT&T to testify that they wouldn't restrict content this way, in order to get government approval for their merger, and then do exactly what they swore they would not do?

This is exactly why no one should ever feel bad about torrenting.</comment>


Show HN: PeekOut - <AUTHOR> https://play.google.com/store/apps/details?id=com.herokuapp.openout.moleheadmain <comment><USER2> Despite the scary pictures on the Play store and name of the app (I expect to see dongs), I tried to install it but the fields for the username, password, etc were unreadable (Nexus 6).</comment>


Cloudonn - like Groupon, buy Powered by People - <AUTHOR> http://cloudonn.com Hi everyone,
Cloudonn is the People Powered Local Daily Deals and Shopping
Cloudonn is find your local daily deals and discounts for health, beauty, services, food, leisure, hotels.
With Cloudonn, deals can be submitted by any business, and people will decide which deals will become "popular" and promoted to the main page (like stories on Digg.com)
As a result all deals local will have a chance to be featured, and people (like you and me) will decide which deals are worth to be Promoted.
We'd be happy to keep you posted about the beta program and launch. <comment><USER2> groupon's (and 100s of others) problem is that they post deals they think are cool (like spas and hair). people want to see something they want to buy. have signed up for your beta. good luck.

</comment><comment><USER3> better launch soon since groupon can simply add "user powered" deals itself.</comment>


Large Public Datasets Repository on AWS - <AUTHOR> https://aws.amazon.com/public-data-sets/ <comment><AUTHOR> There is also AWS Public Datasets ([https://aws.amazon.com/datasets/](https://aws.amazon.com/datasets/)) which are smaller than the "large" public datasets linked in this post.</comment>


Clearing Up Some Myths About Victorian 'Post-Mortem' Photographs - <AUTHOR> https://www.atlasobscura.com/articles/victorian-post-mortem-photographs <comment><USER2> What this article leaves out is that unposed photographs of the dead (particularly children) were common in Victorian times - including in my family. My grandmother had (and I saw and was able to examine) such a photo of a dead infant, perhaps two - her sister. Her father, an interior decorator, was on a buying trip to Germany when the child became ill and died, and this may have been a factor in preserving a momento mori of the child corpse for him to see when he returned to London. Cameras weren't very portable, so taking photographs of a sick child just before death wasn't usually a possibility, as would be the case today.

</comment><comment><USER3> This was really interesting! Just something I believed because "why not?" and didn't give it another thought for many years. There's so much information coming at us from every angle, that if it doesn't have a major impact in my life, I often don't think critically about the information.</comment>


Study of facebook messaging patterns by HP Labs - <AUTHOR> http://www.hpl.hp.com/research/idl/papers/facebook/ <comment><USER2> Interesting, its always a wakeup call to see the amount of real world conclusions that can be gleaned from a (seemingly useless) dataset.

An interesting parallel to human psychology as well: often the people you are quite certain have nothing to teach you are the ones with the most valuable lessons for you to learn.

</comment><comment><AUTHOR> This is the paper where the "43% of facebook messages are spam" claim originates, something which I am inclined to dispute. Other than that its a great look at user habits. The graphs speak for themselves.

<comment><USER3> I don't find it entirely impossible. After Startup School I talked to Adam D'Angelo about spam on facebook (largely because I'd never seen any); he said that there is a lot of spam activity, but that internal safeguards prevent most of it from ever being visible. If the researchers were using internal, pre-filter datasets, their claim is reasonable.

<comment><AUTHOR> Good point. I was concerned that the researches might be counting messages to groups as spam.</comment></comment></comment>


The Mystery of the $70 Hoodie That's All Over Facebook - <AUTHOR> https://www.wsj.com/articles/the-mystery-of-the-70-hoodie-thats-all-over-facebook-1526817601 <comment><USER2> Article is blocked.

<comment><USER3> Try: [http://outline.com/FeHLtG](http://outline.com/FeHLtG)</comment></comment>


Petit Computer brings the power of BASIC to Nintendo 3DS and DSi - <AUTHOR> http://www.gizmag.com/petit-computer-basic-programming-nintendo-3ds-dsi/23410/

<comment><USER2> It's cool that they're putting programming languages where kids _might_ get exposure to them. Of course, most of the reason people were acquainted with BASIC was that it was the _only_ thing that came with a home computer.

Typing might be a bit of a pain though which would limit the usefulness of this sort of thing; a visual language might work better on systems with no keyboard (although I'm not a big fan of them).

BASIC was my first language. About the best I can say for it is that it underscored the sequential aspect of the machine. I'm curious as to what people's first languages were here.

<comment><AUTHOR> My first language was BASIC when it had line numbers! That was on Atari 800.

<comment><USER2> I started with BASIC on a TRS-80 and then C64. When I first saw QBasic, I was a bit offended they took out the line numbers...I mean, how is one supposed to program without line numbers?!

</comment></comment></comment><comment><USER3> Adorable as a cool future-retro gadget. OK, probably not optimal for pedagogical purposes!

I once read about a sewing machine had a gameboy interface (don't remember if it was a hack or OEM). These things are so tough and ubiquitous, it is surprising that they aren't used as cheap interfaces to machinery.

Check it out: <http://www.retrothing.com/2006/04/izek_sewing_mac.html></comment>


How do you like my new personal page? - <AUTHOR> http://www.imrashid.com

<comment><USER2> Looks like youve got some good feedback here already on some minor improvements to fix up.

Overall you've got a nice looking site and an attractive way to introduce yourself. Looks good!

</comment><comment><USER3> I don't like the way the navigation links stay at the top and overlap the text when I scroll down, it becomes confusing and hard to read. It might be better if they had solid backgrounds, but it would probably be best if they either scrolled with the rest of the page or were embedded in some sort of opaque (or very low alpha) bar.

</comment><comment><USER4> Use a black dropshadow, to aid in contrast, on any white text over the keyboard photo.

<comment><AUTHOR> Wow. Pretty neat trick! Thanks for that :D

</comment></comment><comment><USER5> The text in the 'about' section needs indented

edit: and the contact section

<comment><AUTHOR> Thanks. Will update the sections!

</comment></comment><comment><USER6> dont ask us, ask google >> [https://www.google.com/webmasters/tools/mobile- friendly/?url...](https://www.google.com/webmasters/tools/mobile- friendly/?url=http%3A%2F%2Fwww.imrashid.com%2F)

</comment><comment><USER7> The link to Tomboy OSX is broken.

<comment><AUTHOR> It's fixed now! Thanks! :)

</comment></comment><comment><AUTHOR> Hey,

I just finished building my personal website. Any suggestions to improve and make it better?

Thanks!</comment>


AppRTC: video chat demo app based on WebRTC - <AUTHOR> https://appr.tc/ <comment><AUTHOR> Now that all major browsers support WebRTC [1] why isn't it used more for video calls instead of proprietary solutions from Google, Microsoft, Zoom, _etc._? Are there security flaws or ease of use barriers that prevent wider adoption? Is it simply lack of marketing/awareness?

[1]: [https://caniuse.com/#feat=rtcpeerconnection](https://caniuse.com/#feat=rtcpeerconnection)</comment>


Show NH: I built a mobile social network for vegans and vegetarians - <AUTHOR> http://www.appstore.com/vnation

<comment><USER2> do you have any plans to make this more than an iphone app?

<comment><AUTHOR> Yes, I'm getting asked a lot about android but I want to take it to desktop and build on top of it, I have some good ideas.</comment></comment>


Google Canceled the Launch of a Robotic Arm - <AUTHOR> https://www.bloomberg.com/news/articles/2016-10-06/alphabet-executives-canceled-launch-of-a-google-robotic-arm <comment><USER2> As someone who spent many years working on Amazon Picking software... I'm pretty sure there's a few companies that would just hand over a dumptruck full of money if those things actually worked as intended. It's such a hard problem space.

Either Google didn't have it working well enough to sell widely (without embarrassment) or else they're pants-on-head crazy.

<comment><USER3> Big issue is that Google's market cap is huge, the amount of money they make is massive as well. For the risk to brand to be worth it, you've got to have a huge potential to make lots of $$$. Hence why lots of projects get killed. Making 300 million a year isn't enough money to move the needle at google.

I fully believe that's why alphabet was created. Allow the `bets` to not use the google branding and name, and stealthy create new companies that produce millions of revenue, but just not billions.

<comment><USER4> > For the risk to brand to be worth it, you've got to have a huge potential to > make lots of $$$.

Then why not just sell the tech and team to someone else, or market the device under a different brand name?

<comment><USER5> Right, let's dedicate a new department to that. And, just in case other departments start expecting similar leeway, let's make this department clearly separate from the others.

</comment></comment></comment></comment><comment><USER6> IMO, Google suffers from the curse of Oil in corporate terms. As long as they milk their core product they can do just about anything and look competent. Which allows a horribly dysfunctional leadership to thrive.

<comment><USER7> > _As long as they milk their core product they can do just about anything and > look competent. Which allows a horribly dysfunctional leadership to thrive._

Until one day, reality reasserts itself and things start melting down. It occurred at IBM, its occurring at Microsoft, and it will occur at Google, Amazon, and the rest of the tech giants.

</comment></comment><comment><USER8> I was sort of hoping the 'toothbrush test' would involve the robot being able to clean your teeth...

Years ago my father worked in robotics. The product was a very simple robot that took a piece out of a die-casting machine and placed it on a conveyor belt. There was nothing to program of any complexity, this arm had a fixed trapezium with different length sides that performed all the required motion, some sines/cosines/tangents involved to get the fixed path right. Most of the bits for the robot came from the R+S components catalogue, so usual industrial control gear, all 'tried and tested' with warranty, not 'home made'.

However, did it go well? The robot only had to do one job right but it rarely did. It probably only ever was one robot, customers were not exactly two-a- penny for this machine, even though it was in theory a very good machine. It would require on-site attention every week and some weekends. There was no fundamental design flaw, the heat had been considered, but it was a constant war of attrition on the reliability front. I would have to ask how that ended, all I know is that it was doomed, just not an economically viable adventure. Yet this was the simplest of robots for the simplest of tasks, solving a known problem that seemed to make sense to solve.

The main business survived the venture into robotics (sold to the same customers) but a loss had to be accounted for, people were laid of and the industrial unit vacated. A lot of hard work was put into it and the whole company was behind it. But it failed, reliability and support just could not be done economically.

So what are robot arms to be for outside of manufacturing, where Google wants to be with their customers?

If Google did get into the sales of these robot arms and 'learn along the way' there really is a risk that support for customers, 'beta customers', might be as all-consuming as it was for my father with his very simple robot. Then there are no resources to actually develop or iterate the product. You need to have the original creators debugging and fixing the robots in the field and there is a high likelihood that this work would take 10x the amount of available resources making actual development nigh on impossible. Much better to take the long route and get the product right before bringing it to market and avoid the trap.

Building robots is okay if that is your core business or if you have some massive factory that needs them. Here the cost benefit analysis can be done, things tested and deployed complete with a team of engineers to keep everything running. If selling adverts is your main business then maybe not.

</comment><comment><AUTHOR> Pity. Sounds like they had a real product with a real, demonstrated business model (akin to Universal Robotics). Google needs to embrace a bit more of the "just fscking ship" attitude for its moonshots.

(The brand protectionism is really starting to hurt their ability to be scrappy.)

<comment><USER9> This "we must protect our brand" is really weird. If you look at the sentiment here on HN, it's pretty much "Oh great, Google is in the news again. I wonder which product they're sunsetting today". Maybe Google only invoke this for their HW products and not their SW.

<comment><USER10> They've now optimized the process to the extent now that they can cancel them before they launch. Seems like an advance over things thus far. :)

</comment></comment></comment><comment><USER11> Pure speculation here. I can't imagine that the "toothbrush test" is accurate here. There is a large market for robotic arms. And if Google's robot creates any advantage over existing robots in manufacturing, Google could go up or down stream in the verticle.

My guess is that it hasn't been tested enough and/or hasn't cleared the top level of safety in the market. One incorrect swing of a robotic arm could severely injure someone and that is a huge liability for Google's name.

<comment><USER12> From the article, the second half of the toothbrush test is 'used daily by billions of people'. Can you show the robotic arm market that large?

With self driving cars, I believe Google is showing willingness to develop things that could severely injure someone.

disclosure: I work for Google. I have not been involved in toothbrush test discussions and do not work on robotics nor cars.

<comment><USER13> Sure. In the future (~20 years) I expect that a robot around the price of a luxury car will be able to perform tasks such as laundry, cooking, and cleaning (not just vacuuming but nearly all types of cleaning). These robots will be used in workplaces and homes, and the eventual market size is definitely in the billions. These robots will need arms, of course. These arms will be sold by a company that releases a small-volume product early and iterates, not by a company that waits until they have a billion-person product before releasing anything.

<comment><USER14> To be fair - this 20-year-prediction-to-home-robots has been happening since the Jetsons aired in the 1960's.

If anything, the Roomba proved that there is small niche-market demand for robotic automation in the home, and economies of scale for goods follows the demand. Consumers simply aren't going to spend the equivalent of buying a new car for something that can be done by a minimum-wage maid service.

<comment><USER15> "Consumers simply aren't going to spend the equivalent of buying a new car for something that can be done by a minimum-wage maid service"

a leased new car costs the consumer a few hundred dollars a month, which is the equivalent of say 30 or 40 hours of minimum wage labor. a robot that cleans floors, prepares food, washes clothes, folds laundry, cleans windows, serves meals, puts dishes away, feeds the dog, waters plants etc. could work 24/7 (with swappable batteries). i'm not convinced that consumers wouldn't pay that if the technology could get there.

of course we are far from a robot that can do all of that, but in my opinion, the prize to the company that can deliver this is massive.

<comment><USER14> Consumers don't lease appliances, and they're certainly not going to pay $500/mo + maintenance for something that they and/or a maid can do.

It's an inferior service, the same reason the Roomba didn't put Dyson or Hoover out of business.

</comment></comment></comment></comment></comment></comment><comment><USER16> Google does not do a great job at products which interact with the physical world.

</comment><comment><USER17> When I first read "Robotic Arm" and "Toothbrush Test", I imagined something like this: [https://www.youtube.com/watch?v=Ki7lqI6XE2s](https://www.youtube.com/watch?v=Ki7lqI6XE2s)

</comment><comment><USER18> Surely they'll have no problem with open sourcing it then, right?

</comment><comment><USER19> If every Household had such a collaborative Arm on roof-rails they could toothbrush the world.. but no, google is gone.

Replaced by another cautious giant, forced to buy inventors from outside, instead of growing them within. Really sad. Everyone sets there ten-year-till- they-are-gone clock, on this re-mark.</comment>


Objectify: A Better Way to Build Rails Applications - <AUTHOR> http://jamesgolick.com/2012/5/22/objectify-a-better-way-to-build-rails-applications.html <comment><USER3> Someone has to say it: Damn, this looks fucking ridiculous!

First we have the _false_ modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them modular. They can only be modular if the author actually implements them in a modular way (and you can do that in Rails today).

The DI-framework can't handle _change_ at all:

        class CurrentUserResolver
          def initialize(user_finder = User)
            @user_finder = user_finder
          end

          # note that resolvers themselves get injected
          def call(session)
            @user_finder.find_by_id(session[:current_user_id])
          end
        end

What if I later need the cookies/params to detect user session? If I changes the #call method, every single test breaks.

And then there's the added complexity. Now I need to keep track of the route- mapping, default policy, route policies, the route service and the route renderer. Which are now in several different files. And there's not even a clean class-to-file mapping to help me locate it.

Oh, and the premise of testability. Well, this makes it very easy to test units itself, but the more you split your projects into smaller units, the more bugs occur when you mix the units. Sure, you can get your precious fast test runs (and a nice green test), but in reality you're only testing a single unit of a complected app.

EDIT: This reminds my of Rick Hickey's quote from keynote at RailsConf2012:

""We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.""

<comment><USER4> When you start a comment off with a sentence like that, you lose all credibility.

<comment><USER5> I don't necessarily think so. He draws you in with said outrageous remark and proceeds to raise some good points.

<comment><USER4> It doesn't really invite discussion. If you were the original author of the blog post would you engage with the author of the comment?

<comment><USER5> Good point. There are friendlier (better?) ways to discuss flaws.

</comment></comment></comment></comment></comment><comment><USER6> This is not object-oriented at all, unless you learned about object- orientation from Java and its monster frameworks, this is basically a form of data-flow programming. OO is about message passing, here the "objects" do not pass any messages at all, the supposed "objects" _are_ the messages, and the routing of those messages takes place in the configuration in routes.rb, so the objects do almost no message-passing between themselves at all! It is ironic to see this advertised as "better OOP practices for rails apps".

Having said this, I respect the attempt, the problem it tries to solve certainly does exist to some extent, and the solution cannot be completely dismissed very easily.

But please, please, do learn both A) basic history and B) basic theory of the field you are working in. If you try to reinvent everything you decrease your chances of contributing something new manyfold.

<comment><USER7> I've read at least a dozen papers on the history of OO, not to mention books and papers on current practices. This is what I came up with. I made what I think is a pretty coherent argument for why in the article. I'd love to hear your refutation of the points I made in there.

<comment><USER6> You have to think a bit more about what OO really is about. How would properties of your solution differ if you instead of classes split all the code into many very small global methods? The essence of OO is objects freely passing messages between themselves, if you fix all the message routing and put it in a central place you are not doing OO anymore, you loose the most fundamental properties, for example:

<http://en.wikipedia.org/wiki/Dynamic_dispatch>

You also don't have encapsulation anymore, since to be able to perform the majority of the work in the services, the services have to operate directly on data owned by other objects.

How can you combine the policies in ways other than a simple logical AND? How do you combine services?

Others have also already pointed out other issues.

Please don't be offended by the above. Software engineering is unfortunately a field where some valuable content is buried underneath loads of BS, since it is so easy to "philosophize" about it even with just basic programming experience and this leads other people learning the field to easy misconceptions. I do not want to discredit the work you put into this and it might be that in some form something valuable will come from some of the ideas. It is an interesting problem to work on and for me it was an interesting solution to think about, I just don't think you are there yet.

<comment><USER7> > You have to think a bit more about what OO really is about.

If you want to have a respectful debate, I'm completely game. If you'd prefer to continue with your incredibly condescending tone, then I'll bow out here.

<comment><USER8> You need to grow thicker skin, that first sentence was in no way condescending and gives you no reason to just ignore the rest of his comment.

<comment><USER9> No. It may be unintentional, but the tone of stiff's comments is highly condescending.

Exhibit A: Whatever you think about James's choices in this library, he has _clearly_ thought a lot about OOP. It's just silly to start a comment with "You have to think a bit more about what OO really is about."

</comment></comment></comment></comment></comment></comment><comment><USER10> Probably worth bringing up Steve Yegge's 2006 "Execution in the Kingdom of the Nouns": [http://steve-yegge.blogspot.com/2006/03/execution-in- kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of- nouns.html)

I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain experience. This makes for code that is easy to understand, collaborate around, and modify given changing objectives.

That means creating "Policy" and especially "Service" models--extra nouns-- very sparingly. For example, an Elevator was once a nounification of a verb, but people understood it, so it makes sense as a class. ElevatorDoor's good too, but ElevatorDoorOpeningService is probably not good. This is absolutely at odds with strict application of the Single Responsibility Principle.

<comment><USER11> The "Ubiquitous Language" is the label I've seen applied to the idea you're describing. For example: <http://martinfowler.com/bliki/UbiquitousLanguage.html>

This idea of having an ubiquitous domain language and keeping applications and APIs RESTful have been two of the most beneficial ideas I've incorporated into my development in recent years.

</comment></comment><comment><USER12> FWIW there's already a library called Objectify that's a Java-based ORM (lite) for AppEngine:

<http://code.google.com/p/objectify-appengine/>

If you want your project to be found easily (on search engines) I always suggest:

1\. Prefer a made up word to a non-English word (or a word in any live language for that matter); and

2\. Don't choose a name that something else in the same or similar space shares. They've been around longer. It's just going to make your life harder.

YMMV.

<comment><USER13> Furthermore, it's the top Google hit for 'objectify'.

<comment><USER14> Do you really think the OP had SEO as a priority?

Likewise I disagree with the idea that these two projects share the same space. A Java ORM and a Rails metaframework for avoiding ORM are not things which have a lot in common. I think the last time I observed a Rails hacker saying anything about AppEngine was 2007 or something.

<comment><USER13> It will certainly cause confusion. This is just decidedly uncool.

As the lead developer of the Objectify project, and someone who makes a living through consulting related to Objectify, I am highly annoyed. I'm also talking to a trademark attorney to find out my options.

<comment><USER14> Jesus, dude, why not just talk to OP instead? Any lawyer will tell you that if you can resolve your differences peacefully out of court, you should. This seems to be some kind of hair-trigger litigiousness thing you've got on going here.

<comment><USER13> Relax, it's not like I'm setting a court date. I just prefer to know where I stand before I open my mouth, and I happen to work with lawyers who specialize in this kind of thing. Research before action, no?

</comment></comment></comment></comment></comment></comment><comment><USER15> Why are people building frameworks to sit on top of yet another framework to try to write cleaner more maintainable code???

What is wrong with writing your core application logic physically removed from any of these frameworks. Why do people insist on fitting their application into the Rails framework or any other web framework.

Write your core application code in Ruby (or your language of choice), package it in another gem, use tools and patterns we've had all along to plug that code into a dependency for persistence (if needed)...communicate with it through a standard API that you define for your delivery mechanism (i.e. Rails).

I just don't get this idea of trying to contain my application code within the confines of a specific framework.

</comment><comment><USER11> "Single responsibility principle (SRP): ... ActiveRecord::Base already has a responsibility: persistence."

Wrong. I'm hearing this more and more, but let's be clear: Active Record as a design pattern, before Rails, has _always_ been a joining of business logic _and_ persistence. (<http://martinfowler.com/eaaCatalog/activeRecord.html>) It's always been in violation of the single responsibility principle. If you want to avoid that, don't use Active Record! Use a Data Mapper, which specifically separates Mappers and Finders from Domain model classes. (<http://martinfowler.com/eaaCatalog/dataMapper.html>)

I'm not saying you can't move logic out into reusable modules or whatever is being recommended here, but please don't make it out like people are in the wrong when they're using the library or framework the way it was designed to be used.

<comment><USER7> The point I was making was that you can use the library in a different way successfully.

</comment></comment><comment><USER16> Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"

<comment><USER7> Because of SRP.

<comment><USER17> At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent.

Care to give an answer better than "some book some java dudes wrote 20 years ago said so"?

While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO nonsense.

Is not instantiation etc a cross-cutting concern that violates SRP in this instance?

<comment><USER18> > Is not instantiation etc a cross-cutting concern that violates SRP in this > instance?

Right.

Which is why hes also recommending the use of DI.

It's hard to strike a balance between a strong design which takes a lot of time to work within, and one that just allows you to get things done, but once your project begins to grow in size and complexity, and testing becomes even more important, these things really do start to matter.

It's difficult to internalize until it's bitten you on the ass, hard.

That said, if you have a large amount of single method classes, you might need to take a look at why you need them and find a better approach (which will vary from project to project).

<comment><USER7> > It's hard to strike a balance between a strong design which takes a lot of > time to work within, and one that just allows you to get things done, but > once your project begins to grow in size and complexity, and testing becomes > even more important, these things really do start to matter.

The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.

> That said, if you have a large amount of single method classes, you might > need to take a look at why you need them and find a better approach (which > will vary from project to project).

I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).

<comment><USER18> >The whole point of objectify is that it actually makes it pretty reasonable to work this way right off the jump. I would have a hard time believing that it's really any more work to build an objectify app than it is to build a vanilla rails app - at least once you become accustomed to the paradigm.

Sure. I wasn't saying otherwise. What I meant was, in a general sense (prior to really seeing the benefits first hand), it can be hard for people to justify the trade off when they feel like they can just "get it done faster" with a more ad-hoc approach to things. I didn't mean to imply Objectify was some how more difficult (I haven't used it, so I wouldn't dare comment on it in such a way).

>I don't buy that. My project has hundreds of single method classes and it's by far the best factored non-trivial application I've ever seen (anecdotal, obviously, but so it goes).

Agree to disagree, with a caveat. I'm not against having a large amount of "Helper" or in the case of what I'm most familiar with, "Extension" classes (godbless you, .NET Extension classes), but I think if you have so many that they comprise most of your code base, maybe you could consolidate some of them (and maybe you couldn't).

Personally, I try to keep 100% of my core business logic inside of "Service" style classes, and then anything that is more of a helper (in that it performs some work, but not "business logic", and does not require or alter internal state) in either a static helper, or an Extension on the type itself.

For example, I usually end up adding a .ToStart/EndOfDay/Week/Month suite of methods to the datetime object of most of my projects. A "DateTime Service" would be overkill, but an extension method (which is just veneer over a static helper) fits the model perfectly, in that it returns a new copy of the existing datetime, leaving the original intact.

But at this point we're getting pretty deep into the comment tree, so feel free to email me from my profile if you want to go more into the issue - <USER2> love shooting the shit over this kind of stuff. Regardless of any minor difference of opinions, I think what you're trying to bring to the rails community is to be commended.

<comment><USER7> > Regardless of any minor difference of opinions, I think what you're trying > to bring to the rails community is to be commended.

Thanks a lot, man.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> When I was first trying to learn about rails, I asked a friend who had been developing in it for a while about things like DI, and separation of concerns. He told me that those were things you used in Java and .Net because the languages just weren't as... I'm struggling to remember the exact term he used, but essentially "open" or "un-restricted".

He echoed the phrase I've seen elsewhere "Ruby just doesn't need that".

I disagreed with him then, and still do. People like to claim that OOP breeds cargo cult programming and overly cumbersome abstractions upon abstractions (and it can), but some times you really do need that kind of approach to make a large scale project testable and maintainable.

I'm glad to see there are Ruby devs who can see the value in using these kind of approaches. I honestly believe it's the kind of thing you think is a major waste of time, until you are shown the benefit first hand, and you experience the change. Then you start to understand that by spending a significant deal of time up front building your infrastructure, you can save a lot of time down the road.

I know that's how it was for me years back.

<comment><USER19> He probably used the word "expressive", which is how we used to excuse ruby's problems.

It's pretty clear, by now, that we (the ruby community) were wrong about how to maintain projects over time without getting mired in complexity.

</comment></comment><comment><USER20> Objectify is a nice framework, but after reading the examples in README made me feel like I am required to take extra iterations: create new responder files, write more codes for each Responder class, etc. This approach is little tedious.

I personally think that writing reusable libraries using Decorator/Presenter patterns or Modules with ActiveSupport::Concern is simple approach.

Avdi's slides: [https://speakerdeck.com/u/avdi/p/making-little-classes- out-o...](https://speakerdeck.com/u/avdi/p/making-little-classes-out-of-big- ones)

I highly recommend Objects on Rails book: <http://objectsonrails.com/>

</comment><comment><USER21> >One in particular is something I've been thinking about and

>refining for a while now [3]. In this approach, persistence

>objects remain extremely thin, and business logic is

>encapsulated in lots of very simple objects known as

>"services" and "policies". Not all objects in this

>methodology will fit in to one of those two categories,

>but they are two of the most important concepts.

I've seen this division of labor outlined in this DestroyAllSoftware screencast : [https://www.destroyallsoftware.com/screencasts/catalog/fast-...](https://www.destroyallsoftware.com/screencasts/catalog/fast- tests-with-and-without-rails)

As can be implied by the title, one of the side effects of keeping your service logic in their own separate plain Ruby classes is that you don't have to load Rails as dependency which means tests can run _really_ fast.

<comment><USER16> Yeah, services are one of the types that have leaked out of DDD (and probably leaked into it from somewhere else).

</comment></comment><comment><USER22> Isn't this the command pattern, except instead of 'execute' you use 'call'?

Update: not saying that's a bad thing I used to be a Flex developer and all the frameworks used MVCS (Robotlegs being my favorite). Controllers are all commands and Services are used to retrieve data.

</comment><comment><USER23> "The more responsibilities an object has, the _more complex its behaviour_ becomes, and is therefore more difficult to prove and reason about."

Emphasis mine. I don't think this has to be true. Yes, models get fatter, but the responsibilities will have to be implemented _somewhere_ and to me it's simpler and easier to debug when it's as close to the domain model as possible instead of in some abstract/generic model.

Of course, if you have policies and services that apply across domains, then by all means break them out and recompose as necessary in the the models

</comment><comment><USER24> Relevant: [http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and- pro...](http://weblog.jamisbuck.org/2008/11/9/legos-play-doh-and-programming)

</comment><comment><USER25> Not quote Donald K. but I've seen my share of optimizing rails apps that points to the fact that each class added is extra 2-4 megs of RAM. This sort of discouraging rule, looking ahead writing well tested app that does follow SRP and other nifty "literate" practices might cost you big time, tell me if I am wrong.

</comment><comment><USER26> This replaces the controller with classes for each action, a Service? Then responders are automatically called and they do renders.

Sounds nice, would be fine with it as a default, but not sure it warrants doing a big change for me.

<comment><USER7> You can move over slowly by building new components using objectify, and leaving the rest of your legacy app the way it is, if you like. It's designed specifically to be able to coexist with what you've got.

</comment></comment><comment><USER27> I don't get why these models get bloated. If there's a language that makes it east break up classes into any number of components, surely that's Ruby! Mixins, open classes, modules, etc..

<comment><USER7> Mixins/modules and open classes do not separate your class in to multiple components - merely multiple files. As I explain in the article, for separate components to be useful, they have to be "protected" from each other - encapsulation, in other words.

<comment><USER28> Mixins (well, as they're supposed to be used) _do_ provide encapsulation; specifically, they enforce the boundary between _instance scope_ (e.g. access to instance vars) and _method interface_. I view them as a part of a coupling continuum:

[instance methods] --- [composed subclasses] --- [mixins] --- [the outside world]

But Modules provide more than that. module_function allows for unattached namespaced functions which can be referenced by full name, relative name, _or_ imported into the local scope. Great way to express functions which are decoupled from instance state--much like the services and policies you're advocating for. It's an under-appreciated aspect of the language, I think.

</comment></comment></comment><comment><USER29> Does this actually perform faster by being on top of rails or would we need a new Ruby framework to get the most speed optimizations from the services and policies?

</comment><comment><USER14> I have a prejudicial assumption that if you don't know the problem Objectify solves, you haven't worked with a Rails app which has A) a large code base B) a large, active user base and C) a bunch of different features.

The vast majority of people who scale Rails sites (as far as I can tell) do so by breaking their apps into services. ActiveRecord god-objects do not make that step in an app's life cycle easy, and separating persistence from business models is likely to be your first important step when refactoring for scalability. Fragmenting a User model bloated beyond all hope of sanity is almost a rite of passage at this point.

I often think the only Rails developer who hasn't found ActiveRecord bloat to be an irritation and an obstacle to scaling is DHH, and although that makes his opinion on the subject even more valuable than it would normally be, he doesn't talk about it enough in my opinion. Pretty much everyone else, as far as I can tell, responds to Rails scaling issues by creating services in Sinatra and/or divorcing business modeling from persistence logic.

I want someone to challenge my prejudicial assumption here, most of all because I appear to be saying "Rails can't scale," which is BS, but also because I'm very tempted not to take this discussion seriously at all if it doesn't address this point. It's just _the_ crucial point in my opinion. I like the whole OOP thing but to me the decision to use something like Objectify is all about scalability. That doesn't just mean performance; it also means retaining readability when you have a lot of code. Single Responsibility Principle makes code readable.

<comment><USER6> I worked in Rails for the last 6 years professionally, and for the last 4 years on a single application. There are lots of ways to tackle this problem, but it really depends what precisely you have inside those models and there are certainly no universal silver bullets. Lots of people who complain about this underuse Rails features, external plugins etc. I think two good ways to deal with the problem are:

\- Splitting out logical pieces of behaviour into separate modules, especially the ones less central to the core responsibilities of the class. If you look at Rails itself (it's great Ruby code, I highly recommend really reading it), this is the way it is structured, ActiveRecord::Base provides tons of functionality as a single class, yet it still is very neatly laid out into many well-separated modules. See e. g.:

<https://gist.github.com/1014971>

[http://api.rubyonrails.org/classes/ActiveSupport/Concern.htm...](http://api.rubyonrails.org/classes/ActiveSupport/Concern.html)

<https://github.com/jakehow/concerned_with>

<http://blog.waxman.me/extending-your-models-in-rails-3>

Deciding what things would fit well into external modules and what modules to create is a new skill to be learned, but I think it can work well once you do learn it.

\- Things that aren't part of business logic but just handle some more technical matters should be extracted into plugins and not be directly part of the models (for example: special kinds of validations).

\- There is the whole world of OO techniques and patterns that can be applied here just like anywhere else. For example you can extract complicated algorithms into separate classes or use value objects:

[http://api.rubyonrails.org/classes/ActiveRecord/Aggregations...](http://api.rubyonrails.org/classes/ActiveRecord/Aggregations/ClassMethods.html)

<comment><USER14> hey man, re:

"If you look at Rails itself (it's great Ruby code, I highly recommend really reading it)"

I've worked with a member of Rails core, and frequent committers. I've spoken at 10 Ruby conferences at least, maybe 20. I'm familiar with the Rails code base. I once rewrote a few small pieces of ActiveRecord from memory for a stupid project because my wifi was dead.

I agree about it being worth reading, I just want to slow you down there for a second. Otherwise we're going to end up pulling things out and measuring them. I took the time to check your links, although I'd seen most of them already. I'm familiar with concerns and although I think your links are germane I'd have to disagree with this part:

"Deciding what things would fit well into external modules and what modules to create is a new skill to be learned"

As I think I've learned the skill.

What I'm saying basically is that I think you missed the mark in terms of guessing my background but I believe it was an honest mistake.

Egos aside, I agree that modularity matters. And I must admit I had a painful reminder about that skill recently when I built something around ActiveRecord and then refactored ARec out of the picture for performance reasons (the gains were staggering). It would have been less painful with better modularity, but I don't think the pain relief from using concerns would have been particularly great in this instance. Non-zero, but insignificant.

I don't care that much about OOP theory, but the pragmatic issues Objectify addresses seem to come up for people all the time. A year ago Steve Klabnik and a few other people were talking about this and I noticed it then how it was echoing James Golick's (the OP) posts about limiting ActiveRecord's role from a few years before that.

There basically seem to me to be three trends in discussion of scaling Rails: 1) "Rails can't scale" FUD, 2) DHH saying "just add hardware and/or caching", and 3) this idea of decoupling persistence from modeling, basically, reining in ActiveRecord, which I've heard from people like James Golick, Steve Klabnik, Gary Bernhardt, and I think Xavier Shay. Paul Dix wrote a great book about making Rails apps service-oriented, the Thoughtbot guys touch on it in their antipatterns book as well, and it's not exactly a coincidence that for many Rails apps the only gem more crucial than ActiveRecord is Delayed Job or Resque.

<comment><USER6> When I say "If you look at Rails itself" I do not mean you in particular, I mean in general for people wondering about the problem a good lesson is checking out the Rails code, similarly "a new skill to be learned" in the sense that it is different from traditional OO modelling most people come from. I know your blog and I've seen you discussing concerns in some other place, so I do appreciate your background. Maybe being irritated about bad ideas makes me come up more abrasive than usual.

Anyway, the whole discussion so far was about dealing with the problem of large (in terms of code size) models, so I assumed by "scalability" you mean scalability in terms of being able to handle very large code bases, not performance issues. I do not understand how the approach presented here would result in performance improvements? I've commented elsewhere on the problems associated with it, others did as well in a fairly convincing way I think. I do not deny that problems with scaling both in the performance sense and in the code size sense do exist, I just do not see how Objectify solves any of them and I do see how many problems it introduces.

As for breaking your app down into separate HTTP services, I agree this can be useful in some situations, but it is completely different from the approach outlined in Objectify, for one you still get a chance to do (almost) normal OO modelling and structure the code in a reasonable way, even if the message passing is done via HTTP and not simply via Ruby method calls.</comment></comment></comment></comment>


China just blocked its last major foreign search engine - <AUTHOR> https://qz.com/1532064/china-walled-off-microsofts-bing-search-engine/ <comment><USER2> "Foreign" here means "Western" or "American", I suppose. As far as I know, Yandex isn't blocked in China, and they are Russian, so foreign to China. I don't know their market share (they fall under "other", but so does "bing" often), still worth a mention maybe.

</comment><comment><USER3> Can confirm that Bing is blocked in China for me. Having lived in China for the past decade, I've found that increasingly, my VPN has gone from sporadically on to sporadically off. China's internet has become an entity unto itself, divorced from the rest of the world.

</comment><comment><USER4> [https://cn.bing.com/](https://cn.bing.com/) IS WORKING. Testing from Shanghai without VPN.

bing.com is not working.

<comment><USER5> This may indicate a technical issue as cn.bing.com was down earlier too. I'm also in Shanghai. Normally, bing.com resolves to cn.bing.com when there is no VPN, in my experience</comment></comment>