aout

Well, if you hide Karma but still use it in the ordering of the thread then Karma could be derivated. In a day you could extract the data from the posts and build a kind of karma-book with top users etc etc...

Since it's a really big, technical book here are some quick quotes I thought were useful in general:

"This book is a handbook of widely applicable and heavily used design techniques, rather than a collection of optimal algorithms with tiny areas of applicability."

"As a rough rule of thumb, use the simplest tool that will get the job done. If you can, simply program sequentially. If that is insufficient, try using a shell script to mediate parallelism."

"[...] parallelism is but one potential optimization of many. A successful design needs to focus on the most important optimization. Much though I might wish to claim otherwise, that optimization might or might not be parallelism."

It's a very good handbook for advanced developers who use native languages. It basically adresses any problem you might encounter when dealing with sync, locks etc...

Near page 300 the author writes about higher level languages and clearly states the shortcomings of these new types of programming. Not sure what to think about it. Are we really discussing the usage of high level "scripts" to handle heavy computations in the 10 next years? I'd love to hear a math or physics Ph.D about this.

EDIT: I mean, Wolfram is kind of a "ultra high level scripted platform" and seems to work pretty well. Isn't that the future?

True, but picking is only one pass of rendering (and a pretty fast one as you can see here: https://github.com/aout/SAGE/tree/Multipass/Sage3D/Resources...).

Your browser is slow when applying transform to DOM elements because it has to translate everything 3D in terms of JavaScript and DOM. If you want to manipulate images and elements effectively in 3D then you have to learn matrix computations, quaternions and stuff which is horrible for the common web developer. I'm saying that if you offer a new approach that could mix HTML/CSS and encapsulate those complex 3D concepts it would be interesting.

Because you could do something easier to understand in terms of 3D for a very simple use case and find a generic use for it.

Just updated the repo with multipass rendering including picking and lights. Might interest you.

I tried the demo of course and I thought you did a great job. I'm not saying you should abandon the project because of performance issues you'll encounter but rather focus on simplicity with clear boundaries. Again, go for it! (but don't go too far)

Well, your browser is already GPU-accelerated. What makes it slow is the process of making GPU-memory accessible to your JavaScript.

An example of that is drawing a DIV and applying a CSS 3D Transform to it. By doing so you'll modify it's display on the screen so you'll need to recompute it's actual bounding box. If you compute the BBox on the GPU and never access it anywhere else, everything is fine but as soon as you have to use it in JS you're screwed because you'll have to transfer data from your GPU to your RAM. Doing so at 60fps is very expensive, then you'll take a performance hit from JavaScript being usually slower than C/C++.

That's not the only problem you'll have, text rendering is probably the biggest one. As you might know, textures are rendered using memory friendly algorithms. To ensure maximum readability and quality you'll have to (1) use a lot of memory and / or (2) apply some advanced filtering so your texture doesn't lose quality. Those techniques are quite hard to implement if you're not a 3D programmer (just check what happens if you try to rotate text in CSS and select it) but more importantly you'll find yourself reinventing the wheel.

Wait wait wait... Handling textures via CG Buffers is quite fast you are right and you can basically do whatever you want in terms of image manipulation using the shaders but you'll lose efficiency as soon as you introduce complex picking (text selection for example) and / or computations (aliasing etc...) between JS and your pseudo-DOM.

In the end the only difference you'll have compared to the real browser renderer is that you do less computations from CG(GL) to RAM (JS), hence the performance.

You can check this very old project of mine where we tried to link DOM and WebGL Nodes: https://github.com/aout/SAGE

edit: just saw the repo wasn't entirely up to date. Done now.

Completely true. But is it so hard to imagine a fallback instead of a rewrite / refactor? I mean, aren't you tired to develop for X renderers? Couldn't Microsoft adopt something like the Khronos group for once and stop fucking around with proprietary bullshit?

It is a fairly common practice in companies that do not have technical managers (http://en.wikipedia.org/wiki/Code_coverage). Basically it is useful to measure the coverage of existing conditions (and insure stability) but clearly lacks the ability to test the conditions you forgot to write. Kind of defeats half of the purpose.

I'm not sure I fully understood the moral of the article but it seems to me that all of these findings are basically what "people knew for a long time". Okay it's good to put data on "beliefs" but is it really useful when quantifying "promoted usage" and "obligation" has failed?

The article does prove that some people tried to impose (via management or structure in large organizations) metrics on coding as a way to rationalize the development quality and miserably failed but clearly lack the counterpart: what happens when you don't impose these metrics? Experience is important but that's not new is it? In the end it just feels like: small programs won't have much problem as do small organizations - Big organization should function like small companies. Not much of an answer.

Also, I'm not sure that a manager saying something like "according to data, we need one more month to make the program 35% more stable" is a good argument (or even a new one). What would be interesting is to try something like "ship the program one month earlier and dedicate the two remaining month to fix what's broken according to feedback", then compare with the first approach.

Based on your speculations I'd say that the QRCode is the IP adress of the WebApp + some kind of token. Scanning it allows the phone to connect to the browser and act as a proxy to transfer messages?

I would add that Acompli isn't on the AppStore anymore so it's probably a pure rebranding of the app.

What's your opinions about a mobile first mail client that helps you connect through mail instead of What'App or Skype? What about persistant folder move if you have a clear indicator that there's something new in a folder? What about highlighting sections of mail for later use?