upthedale

How about over one's own DNA? An honest question... no snark intended.

You've got the correct offset, but it appears you have some extraneous data at the end.

The offset is 0x20b94, with length 82244. Pull that out of the jpeg, and you can play the song.

The facebook announcement was already on the front page, but then magically vanished, https://news.ycombinator.com/item?id=5416021

How can I pull the backgrounds out into simple image files. I'd love to use the top 3 images in the blog post as desktop wallpaper (but they're too small - avoiding copyright issue perhaps?).

Or are they just in-game screenshots - small views of the larger textures (explaining their tiny size in the blog?)

The REST API looks like its halfway to being an OData one. Why reinvent the wheel and not go the whole hog?

I've bought it in Tesco's ethnic food aisle in the past. And my local Asian food shop.

I agree with your latter point. MVC isn't the last word in architectural patterns.

However...

> Because then it's not really MVC anymore. It's something else, perhaps inspired by MVC, but not MVC.

I fail to see why the example I gave does not follow MVC. You have MVC on the server (as people have been familiar with for a very long time. Nothing new here). In turn, that data produced by the view on the server (could be HTML, XML, JSON, whatever) can form the model of a second MVC architecture on the client side.

What exactly isn't MVC in either the client or server? The only thing I can thing you might take issue with is consuming the model from the data sent from the server, but I couldn't explain why. This is still in keeping with the MVC pattern, which in no way prescribes that the data has to come directly from a database (or whatever else the server's model's state is formed by).

Or is the problem with the server's view not generating output that is necessarily HTML to be looked at, but data to be further consumed? Again I don't see how that doesn't fit in with the MVC framework.

Why can't MVC be compositional? The model of the client can come from the server's view. For example, a server could follow MVC, where the view is responsible for forming the data (such as in JSON or XML). In turn, that could form the model for the client's use of MVC.

Samsung Smart PC Pro (include ATIV in the name for North America I think). Ticks all the spec boxes you mention, but is a bit above the price range.

I like it because it can be a full laptop, with real hinge (unlike the Surface Pro), but can still detatch to be a real tablet. Coupled with the official 360° handstrap case, I don't find its heft to be an issue in tablet mode either.

I was unsure about whether I'd have use for the stylus when I bought it, but it has exceeded expectations. It is great for inputting short text here and there (e.g. searching the web). It is also great for having finer grained input for those occasions when I want to drop into the Win8's 'desktop mode' without switching the hardware back into 'notebook mode' (i.e. avoiding the need for the mouse pad for casual usage).

The announcement 2 weeks ago was just for public availability. Its been public knowledge for much longer. See this from last April: http://weblogs.asp.net/scottgu/archive/2012/04/16/announcing...

Seems related to the big Xbox roadmap leak from earlier this year. 'Fortaleza' was the codename I think if anyone wants to do some digging.

My favourite article for laying out some scientific reasoning behind skipping breakfast is the following:

http://articles.elitefts.com/nutrition/logic-does-not-apply-...

Nice little experience as an Opera user when enabling the 3D view. It recognised my browser and explained quite simply how to enable WebGL. (Go to opera:config#UserPrefs|EnableWebGL and set the value to 1).

I think other websites could learn something from this, instead of thrusting a link to 'upgrade' my browser to chrome or safari or flat out failing.

Doesn't Windows 8/RT do this too?

OK, conversely, you're saying that you should do the wrong thing (as in this case), if there is no financial incentive?

Given you aren't going to get a reward either way, why not do the right thing?

Frankly, I can't believe I need to discuss the morality of this. Is it not obvious?

And yes yes, I realise this is probably a case of Hanlon's Razor, not a moral failing, but justifying it on the grounds of there being no reward is crazy.

So you're saying you should only do the right thing if there's something in it for you?

Looks good.

However, my big criticism of these sorts of visualisations is they seem to be entirely geared towards imperative programming. Has anyone seen similar visualisations for more functionally structured code?

Oh, I see you can write your own code to be visualised. Here's a simple list comprehension: http://pythontutor.com/visualize.html#code=myList+%3D+range(...

Not the most enlightening visual.

Don't forget Rx [1]

It enhances support for the IObservable/IObserver interfaces, the duals of IEnumerable/IEnumerator, allowing Linq manipulation of asynchronous events.

As others have discussed or at least alluded to, C# certainly started out on a par with Java, but has grown into a different beast altogether, if one makes use of all the new developments mentioned.

These days my C# code is very un-Java-like, and far more Functional.

[1] http://msdn.microsoft.com/en-us/data/gg577609.aspx

Its too late for me to read through in full now, I'm afraid I'll have to defer that to tomorrow.

However, when coming across anything to do with writing async code in .Net, my immediate question is how does it compare/cooperate with TPL, Rx, and the new async/await keywords. From skimming, it doesn't appear these are mentioned at all.

Is this of any use in the .Net4/4.5 world? Or just for writing code from the .Net2 era? (Or Unity/Mono, which I'm not so familar with).

I agree, and I also take issue with the term 'churn'. Churn would imply that features are being removed, replaced with these new ones.

What we are instead seeing is growth of the framework, and community.

To offer an alternative viewpoint to your later point, wideroots, I find the TPL based Task Asyncronous Pattern introduced in .Net4 much more useful that older patterns like Begin/End (APM) pattern, or the event-based pattern (EAP) . I'm looking forward to using the new async/await keywords too. Some things I could rewrite, some things will be better using the underlying tasks directly, and for some things I use other supplementary async technologies, such as Reactive Extensions (Rx) and TPL Dataflow.

But this is just an example of growth, not churn, as the older patterns are still valid, and the community can choose.

As an anecdotal counterpoint to your last sentence, I'm not using these technologies for small applications, rather the complete opposite end of the spectrum. My observation is that the community is embracing these new tools. But again, this is just an example of growth of the community, not churn.

Definitely. Should have left that first line out, as it wasn't what I was trying to argue. The rest of my point still stands.

Edit: I see you've appended to your comment. The problem is you could always have lazily-evaluated IEnumerables by implementing an IEnumerator. It was just a pain in the arse until C#2 brought us generator support through the yield keyword. This was long before Linq came along.

Edit2:

  > There were years and years where IEnumerable simply defined an object that could be enumerated...

Which is my point exactly. And nothing has changed with IEnumerable (generics excluded). It certainly doesn't say that all the objects are already held in-memory (as enforcing ToList would do). By returning an IEnumerable, you're just saying here's an object that can produce you a sequence of results. In a public API, it should be documented (at least some vague allusion to) whether this will be produced by trivially pulling them out of an in-memory list, or whether something a bit more clever is going on, as there'll certainly be occasions where streaming the results through a generator is more desirable than holding them all in memory.

But if you're ToListing it, your return type might as well just be List, not IEnumerable (or IQueryable).

I feel that by declaring your return type as IEnumerable, you're implicitly saying to any caller that the return object is something that can iterate (and potentially generate) through results when requested, and so care should be taken with its use (to avoid getting multiple IEnumerator objects, and iterating unnecessarily).

As I've said elsewhere, this functionality should be embraced.

One of the ways the caller might prevent iterating unnecessarily may be to call ToList or ToArray. Alternatively, they might structure their calling code better. Either way, it should be the caller's choice, instead of being imposed by the underlying method.

Oh yes, I did actually realise that. Thank you though.

I worded it badly. I should have been clearer in that I was following on from solutionyogi's argument about readability.

The compiler example is a bit on the ugly side, wouldn't you say? To then access 'keywords', it becomes

  ...
  .Where(anon => anon.keywords[0] == "verybadexample")
  .Select(anon => anon.post);

What I should have said was that I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods with the same level of readability.

Absolutely. You saved me writing the same thing.

Regarding point 1, I would add there are also things that can be done using the query syntax that simply can't with the extension methods. For instance, I'm not sure how you would scope things in the same way as the 'let' clause when using extension methods.

Regarding the other points, I would only add that deferred execution and lazy evaluation are things to be embraced, not hidden away and overriden. Should we also not bother with the yield keyword?

Of course, there's always some occasion where you'll want to ToList your IEnumerable. I'd argue this should be of concern to the consumer of the IEnumerable though, not the producer.

Point 5 at least tries to allude to something useful. Given Linq's grounding in functional programming, of course you want to try to avoid side effects.

> On a side note, isn't the term "freetard" extremely pejorative?

This is The Register we're talking about. I see it as no coincidence that it has a red banner, it is a "Red Top" of tech journalism

http://en.wikipedia.org/wiki/Red_tops#Red_top

Not only that, but the user accounts can optionally live "in the cloud", such that a user - who would otherwise be a guest - can use another's device and keep their preferences by having them synced up automatically.

The link I gave was just my lazy attempt at citing something. Wikipedia is hardly reliable source No. 1.

In reality, it is my understanding the Windows RT (the OS), can only run applications designed for Metro/WinRT (the runtime). That is, any Metro application out there should be compatible with both Windows 8 and Windows RT (the OS).

(There may well be gotchas around reusing some native libraries, but I suspect these would be few and far between).

So to your earlier 'bet' you went against...

> ...Windows RT will have more apps at launch than Android tablet currently exist.

Well Windows RT (the OS) should have the same number of (Metro-style) apps as Windows 8, given my understanding from above. I'd expect this to be a pretty high number once the devices hit, given that Developer Preview (and therefore the tools to make these apps) have been out for nearly a year now.

Counting the number of Android tablet apps is more difficult. I wouldn't count the full total of Android apps, only ones optimised for a larger screen. First you have to define it. On Google Play's store, I could only find one list of apps for Tablets, which only has around 250 apps: https://play.google.com/store/apps/collection/tablet_feature... (Given that I was able to get to the 11th page).

If betting the number of Windows RT apps against 250, I know which I'd put my money on.

Of course, there may well be more than 250. How on earth does one find them though?

(In my quick searching, I came across this article from the honeycomb days, which still seems to apply: http://pogue.blogs.nytimes.com/2011/07/01/mystery-how-many-a...)

This isn't correct. From http://en.wikipedia.org/wiki/WinRT "Programs can be written using Windows Runtime that will run on both the X86 and ARM editions of Windows 8 without modification."

The entire point of WinRT (read: Metro-style apps) is the you can code it once, and it will run on either platform.

> Why would a developer spend time working on Windows RT software

Because they don't have to spend any extra time over writing the same application for x86-based Windows 8

This doesn't really address any practical issues you faced in holding down a full-time job whilst also building the startup.

Based on the title, I was expecting more. Something like how you managed your time?

That said, congrats on launching.

I wonder if its possible to wrap an Android emulator in the Metro shell.

Would make buying an Android tablet pretty pointless.