tabbyjabby

I'd just like to note that that is not a particularly OO solution. You've essentially created a namespaced function. While this is still preferable to a bare function in a heterogenous helpers function file, it's certainly not a pure OO way of accomplishing the encapsulation of the InputSanitizer.

Of course the Hash class in Ruby implements a hash table. What makes you think it doesn't?

what platform? I just fired up a version of FF on Mac OS X with the identical version you are using and everything seems to be working.

sorry to hear about your issues, snogglethorpe. what browser are you using?

hey zoba,

are you able to access this URL[0]?

[0] http://www.recitethis.com:8901/socket.io/

Just a note about your 'lack of LTE as a feature' argument: I think you would be hard pressed to find many objective observers that would agree with that opinion. I have an iPhone 5, and the network speed difference is extremely noticeable as compared to 3G speeds. To top it off, the battery life is roughly equivalent to my iPhone 4's. I certainly do not feel like a compromise has been made between the networking capabilities of the chipset and the battery life. I think you will find that most professional reviewers who have written about the iPhone 5 will agree on this point.

This sort of spin is inaccurate at best and disingenuous at worst. It subtly reminds me of the hackneyed "it's not a bug, it's a feature" spin. Attempting to transform what is almost universally considered a positive into a negative is not what is going to lead to Google selling many of these units; it's the very competitive price point. It seems like an extremely solid device, and I think that Google consciously made the trade off between price and networking capabilities. I doubt they would have been able to sell these handsets at such a low price if they had LTE capabilities.

It also explains why the Nexus 4 come only in 8 gb and 16 gb capacities. Google has decided that pushing the price is down their primary objective. It's a very smart strategy. I'm sure Apple is very afraid. Their business is built on making high margins on hardware. I wouldn't like being an Android handset maker right now though either. It seems like Google is on a mission to make low margins and low prices the norm for tablets and handsets. One only needs to ask Dell or HP how that sort of market turns out for the hardware manufacturers. Google has nothing to lose, because their ultimate goal is marketshare. They aren't worried about slim hardware profits, because that's not where their core business is.

I am extremely doubtful that optimized C is going to be equally performant as optimized JavaScript. There is innate overhead when using an interpreted language, no matter how advanced the interpreter. JavaScript is also garbage collected, while C is not, adding an additional level of overhead.

At no point in this article are we shown the code of this new parser. We are also told that is incomplete. So we have a parser which we can't see and which is not finished, but apparently dominates its C counterpart in performance. This leads to me to believe one of two things:

1. The parser isn't complete, and its unimplemented functionality is going to be more expensive in terms of performance than the author anticipated, thus rendering his preliminary results void.

2. The implementation of the C extension he is comparing against is not very well optimized. As said above, I find it very hard to believe that well optimized C is going to be beaten by well optimized JavaScript.

What was the the big feature of the iPhone 3GS?

Please read this article[0] and educate yourself. The amount of misinformation surrounding the Apple-Xerox relationship is dizzying.

edit: this article[1] is a bit briefer, and provides much of the same information.

[0] http://obamapacman.com/2010/03/myth-copyright-theft-apple-st...

[1] http://www.folklore.org/StoryView.py?project=Macintosh&s...

I think the routing in that example is meant to be Sinatra-style routing for lightweight applications.

Sure.

The founder (Daniel) has been involved in a number of businesses. If you had read his description, even just glanced it at for more than a second, you would have seen a fairly long list of businesses with which he has been involved. He is the co-founder of visualize.me, the founder of Everyguyed (a men's publishing network), and the co-founder of a design agency, amongst other things. I can't speak to his experience with M&A, but it would seem unlikely that he would have a hand in running so many separate businesses without at least being exposed to some M&A experience.

As someone else pointed out, the advisors of the company also have M&A experience.

Also, Piccsy was founded at around the same time Pinterest was, so it's untrue to say that they are simply following in their footsteps.

Firstly, I'm not sure how much of the pitch deck you actually absorbed. Much of what you said is not "factually" true.

Secondly, why would creating a well-designed pitch deck be an antipattern? They have 3 million plus uniques a month with a very healthy average time on site. It's not like they are ignoring their users and the growth of their company so that they can instead just waste their time crafting elaborate pitchdecks...

Canada has the lowest debt to GDP ratio in the G7. We've been in surplus for the greater part of the last decade, and are soon to be back in the black. Broke? I'm not so sure about that.

Ok, but in this specific case, the premise of this being an item that is stealing attention away from the more significant cuts in the budget simply isn't consistent with reality. Go to any national Canadian newspaper. The headline will not refer to the elimination of the penny; it will refer to changes to Old Age Security, or cuts to the CBC. The penny has been but a footnote to budget news. The reason that is the only item of the budget getting attention on HN is because I don't think any non-Canadian HNers really care that our retirement age is now 67, or that health transfers to the provinces have been reduced in this budget.

This might be a good step, but we still haven't heard a plan from RIM on how they plan to adapt to the changing landscape. A shake up of upper management is good in principle, but it isn't an end to itself.

I'm curious; what data structure and algorithm are you using to achieve O(log n) routing?

Cool. How does it turn the HTML into an actual jpg image?

Really looking forward to traits. We have some hacks using interfaces and __call that we have been using to try and approximate traits, but the real thing is always much better. :)

I'm inclined to believe this is an error. I have wasted hours trying to figure something out in a textbook, before I decide to check the errors section and discover that it was just a misprint.

Bit confused here --

The author rewrites the initial values as:

1 0 2 0 2 3

He defines the keys array as:

2 3 4 6

Using the method defined in the article to find the values of each of the elements of the rewritten array, wouldn't the values be:

3 2 4 2 4 6

which does not equal the original values of:

3 2 4 6 2 6

Do your Sinatra apps have access to the Rails models?

I think largely non-blocking I/O is a means to an end. Non-blocking I/O allows one to implement a single-threaded event loop, which allows one to skip all the overhead associated with multithreaded systems. It's not the non-blocking I/O which necessarily makes it more scalable, it's the fact that you avoid the heavy cost of context-switching and the memory and CPU complexity of thread creation.

Yeah, except you lose the morning/night distinction, because they also suggest that the entire world use one timezone. This, in my humble opinion, seems to a very cumbersome and onerous system. Yes, there are obvious business advantages to having just one timezone, but it also completely robs us of heuristics that have been developed over centuries.

What are some of the problems you deal with when coding PHP on a daily basis?

Look, there are a number of criticisms of PHP that the language definitely deserves, but I'm not sure if you've hit on any of the legitimate ones.

the outright necessity of shit like call-by-name loses what little error-checking you can otherwise get

I'm sorry, but I use PHP everyday, and I rarely find myself needing to use call-by-name, except when it is required by internal functions. Many internal PHP functions that manipulate arrays do require the arrays to be passed by reference, but this doesn't prevent unit testing or error checking at all. I can't find any validity in this complaint and am assuming it is more problem of your coding style than an error inherent in PHP's language design.

the solution to any data storage problem seems to be "MORE ARRAYS!"

Brilliant observation. This is because arrays in PHP do double or even triple duty. They can be simple number-indexed arrays, they can be associative arrays, and they are internally implemented as hash tables, so they can also act as hash tables. Is your problem a semantic one or one of functionality?

PHP is a tool where a sufficiently advanced developer finds themselves fighting it as much as using it, and that is a shame.

Sorry I can't be as advanced as you.

Montreal, Canada

Sorry, I didn't mean to come across as a dick. I'm glad that you've taken the feedback of your readers into consideration.

I'm a big fan of Redis, and it's a key component of our stack. Sorted sets are useful for a lot more than just leader boards, though that is a good use case for them. It's a bit late here, so I'm not feeling up to writing a big post, but I'm considering writing my own blog post on my experiences with Redis.

Because you might want to use sets to group any type of keys, including hashes.

Redis is single-threaded. Also, not everyone uses stateful app servers.

Why is it more efficient to store everything in individual k-v pairs? Hash tables are certainly more memory efficient, and the difference in CPU efficiency is so slight as to be inconsequential.