267 karma · joined January 29, 2012
Makes PR reviews a bit confusing at times.
Still, the final results felt similarly weird. The winner was a (non-technical) dude who had been pitching his startup for months already and found himself an amazingly talented developer at the hackathon. They made use of most of the sponsor APIs and added PayPal as a payment option for the already existing service. To me it felt like the guy was just going to random hackathons so he could get work done on his website for free. Even though the developer seemed to be exceptionally good, it seemed like he was just being taken advantage of by a guy who couldn't get his startup to have more traction.
There were definitely much more impressive hacks out there. (Mine honestly wasn't one of them, so it's not just jealousy talking). In addition, the theme of the hackathon was 'solving local problems'. Now if not having a platform to get product X in city Y is a local problem, it might fit. For me though, the interpretation was more 'making the world a better place' and not 'building a purely profit-oriented application to sell stuff using PayPal'.
I think they simply chose the most monetizable product that was in the competition. Made the whole event, which, I repeat, was about the best organized and executed hackathon I've ever seen, suddenly feel cheap.
db.load()
.then(setupDB)
.then(collectData);
You are currently basically throwing away the value you `resolve` with, where you should instead resolve with what would be the return value if it was a sync function so you can `.then` the function that takes the return value and returns a promise to be resolved with its return value.
// Sync
var foo = function () { return 'foo' };
var addBar = function (foo) { return foo + 'bar'; }
addBar(foo()) == 'foobar'
// Promise using Q
var foo = function () { return Q.resolve('foo') };
var addBar = function (foo) { return Q.resolve(foo + 'bar'); }
foo.then(addBar).done(function (result) {
result == 'foobar'
});The only thing that really matters is the size of the set of numbers that you do your computation on.
What's really going on here (not in code but conceptually) is that you have two steps. First you take a number `n` and basically convert it into a generator for the set of numbers `{0, ..., n-1}`. We can assume that to be a O(1) step. Then in the second step you apply a O(1) function for every number in the set which is clearly O(n). So you end up with O(1) + O(n) which boils down to O(n).
So we have functions
`g(n) -> generator for {0, ..., n-1}`
`f(x, funct) -> funct(n) for n in x`
and we combine them into
`p(n) -> f(g(n), print)`
Clearly, the input size of the arguments to `p` is no longer meaningful for the total runtime. You have to assume it is a set of numbers to make any sense.
So in my opinion while anonymouz is technically correct, it does not make any sense to see it that way. BigO notation/analysis is there to gain some understanding about your algorithm complexity and not to link the amount of digits in a number to the complexity of your algorithm.
It's not about squashing together the entire history of development.
In this workflow there is no pushing to master because you never work on master. So there is no reason to ever rebase master. Master is always assumed to be published history.
For me, one of the main problems when scaling the Backbone app I work with is decoupling View interactions. Now the usual recommendation you receive is using an event bus. In the link @analog just posted [1], Addy Osmani talks about using the Mediator pattern to achieve the decoupling, which certainly does help, but imho his example does not fully reflect the purpose of the Mediator pattern. His Mediator is barely more than just an event bus.
A Mediator can make use of an event bus, but an event bus is not automatically a mediator. It still forces the views to know about events triggered from other views and react to them. This still causes coupling, and even worse, it keeps the coupling in the views. The mediator should exist to take care of that coupling and pull it out of the views.
Let's take for example a checkout page. The checkout page has a view containing a form for address data. It also has a view that lets you pick the payment provider, a view that allows you to enter a coupon and a view that shows the order total.
Here are some of the required view-to-view interactions:
* If the user email changed, revalidate the coupon to make sure the "new users only" constraint applies and show the status
* If the payment type is changed to Paypal, add an additional charge to the order total and display it.
* If a coupon is entered, update the order total
This means that in many cases, views need to know exactly how the public event interfaces of the other views look, even if they communicate by an event bus and not by direct references and method calls. To make the application maintainable, we need to get rid of the knowledge about the other views' events as well.
This is where the Mediator comes into play. We make the mediator aware of the different event interfaces of the Views and have it decide which events to retrigger or which methods to call in what View. Instead of having the views subscribe to the other Views' events, the Mediator wires them up and encapsulates the View interactions. The Mediator now knows that the `change:email` event from the AddressForm triggers the `validateCoupon` method on the CouponView or the `validate:coupon` event to which the CouponView listens. The CouponView no longer needs to know about the existence of the `change:email` event.
Now the Views only need to specify their public (event) interfaces and the Mediator knows about how the different Views interact. This is a lot more scalable than the naive event bus approach.
I really wish there were more articles about scaling really big JS applications. In the end they will probably heavily borrow from GoF's Design Patterns book, but it always helps to see the patterns in action. I appreciate the author's effort, but I always feel disappointed when I read "Large Scale (Backbone|JS) Applications" and don't find advice to solve and real problems what come up with scaling "Large Scale (Backbone|JS) Applications".
I think that's a terrible and even dangerous attitude - especially when done in public - for several reasons.
Firstly, if you heavily criticize something when many people are watching, it might keep you from receiving balanced feedback. Some people probably liked some of the aspects of the redesign, but with dozens of people in the thread saying how awful it was, they will rather not speak up and talk about what they liked. If you tell a mass of people "X is rubbish and whoever came up with this is stupid", and some more people join in, the others will probably assume they are idiots for liking it and say nothing. As an analogy: When I was younger I really liked a girl in my class but all my friends were going on about how ugly and weird she was, probably because of some kind of social feedback loop. So instead of telling her that I liked her, I started joining in with the "X is stupid" meme because I didn't want to look like a fool in front of my friends. Had they not talked about it in such an extreme way, things might have went differently, but because of the situation, I lost all my courage to admit it to her and my friends.
Secondly, if you mix valid criticism with being a dick about it, people will more likely think that your criticism is less valid since it's easier to just assume you are an asshole. Most people are emotionally attached to their work. If they weren't, their work would probably suck. They'll learn how to handle criticism, but that doesn't mean it won't hurt or demotivate them if you tell them it's rubbish.
Thirdly, there is absolutely no need to ever mention that it's rubbish or awful. All you need to do is to list the points where they failed and maybe give advice on how to improve it. Calling their work rubbish helps nobody and makes you feel smarter and more powerful than you actually are. If you treat people like this, their work will become worse, not better, and at the same time they will probably stop asking you for advice because you can't stop being a dick about it instead of just encouraging them to improve on what they did by giving valid advice.
People aren't just machines that you can tell "this is all awful, throw it away and start over" without hurting their feelings in at least some way. You should learn to use these emotions to steer them in the right direction, not condemn them and call people who express them unprofessional. You'll get a lot further by nicely packaging your criticism.
I was thinking the same thing. Maybe it's not so much that people in India click a like button ten times as much, but that more people in India get to see the ads. I assume Facebook somehow reserves ad space for you, but since many more people advertise in the UK, they can only show the ad to the target audience every 1 out of 100 page views, while it might be 10 out of 100 in India. If you advertise in India and the UK at the same time, Facebook will probably reserve a lot more slots in India, because that's cheaper for them. If they want to maximize their revenue, it would be smart to sell the sought-after UK slots to companies that can pay a lot. Indian likes are cheaper because more people want to advertise in the UK but there are fewer slots, so UK likes become more expensive.
Probably not going to happen before they release their new gaming console. They need a good launch title and you know how long it takes them to build a game.
It's still a joke, but it's more than just setting cookies.
A part of the system figures out what resources are requested the most and caches them. Then it sends them over to the client together with a minimum page skeleton that can request more things once it's loaded. Based on the cookie, the system knows what additional parts that are being rendered in the background so once the cached parts are loaded, the remaining things can be delivered. This makes it possible to instantly respond and start rendering the website so tasks that maybe take 200ms to compute on the server side don't delay the response.
This is the first time I read an entire software patent. If all it takes to get one of those patents is taking a simple concept and blow it up to 11000 words, I must really ask myself why I spend my time writing software and not software patents.
Even though I think this is a nice idea for scaling high-traffic websites and having them be responsive also when server-side rendering takes relatively long, this is something that belongs in a technical blog post, not a patent. Being able to patent those kind of "inventions" really doesn't seem to benefit anyone.
The impression I get from the (software-)patent system is that its only current purpose is to have a cold war style arms race so large companies don't just nuke each other. In the end, all the big players have tons of "nuclear weapons" in their basements that they cannot get rid of and everybody else has to be afraid of pissing them off by competing with them.
The longer patents like this one are allowed, the worse the effect on business and innovation. This really has to stop.
class="teaser-imag-container"
Backbone takes care of syncing your data with the server, provides you with an event system so you can subscribe to changes, gives you a sane convention for how to structure your views and then gets out of your way. It's also easy to extend, so you could write your own data-binding system if you really need it. A simple 1-way data-bind is quite easy to implement.
If you aren't writing a single page app and only need to make a primarily static page more interactive, Knockout is probably the right choice. If you are writing a single page app, you often need to sync your models and collections with the server, or if your UI is very complex, Backbone is probably better.
It might be because my eyes are still young, but I prefer smaller screens with a high pixel density to larger screens with a lower pixel density.