jalfresi

Why not ask the same question of Nike or Addidas? The number of people who wear sportswear for fashion FAR outstrips those who wear it for sports alone. And that cash cow seems far from milked, what with the recent fashion trend of athliesure...

My point is, tech literacy is irrelevant; the lifestyle brand is everything.

I'm quite naive regarding Power processors; does anyone know where I can see any motherboards with prices for power processors, or even if any of the BSDs run on them? It seems like it would be quite a nice platform/OS combination that side-steps the traditional Apple/OSX vs Intel/Linux workstation options

Not everyone needs a distributed solution. Sometimes, "beefing up the box" is enough for most systems, not everyone needs Facebook grade scaling tools.

As they say, scaling is a nice problem to have.

Which would make things a lot more complicated - vs. issuing a move command on a job id where the server would be responsible for making sure the atomic move succeeded.

It's not a difficult feature to implemented (in fact if I recall there is a pull request open for this feature in beanstalkd) and IMHO would open up a lot of interesting use cases.

I quite like text based protocols like this, beanstalkd and memcache. Very straight forward to write clients. Each interaction is stateless, and writing clients is trivial.

Thats not to say a HTTP interface is that much more difficult to add these days.

Dunno about SOOPER GENIOUS, but I reckon he knows his stuff. He's certainly got the chops that prove it.

The idea was that you would reserve a job in a tube, do some work, then move that job to another tube upon success atomically, without the need to delete the job, then create the job in the new target tube. The problem is that if you create the job in the new tube before deleting, the TTL could kick in and return the job to the original tube, meaning you have the same job in both tubes. The other alternative is to delete the job then put it in the target tube. However, if your worker process dies during this step, you may end up losing the job.

This appears to be similar to beanstalkd but with some nice additions (scheduled time for job to run, jab max existence time).

One of the things I awlays wanted beanstalkd to have was an atomic move-tube command, so you could emulate a state machine using queues and tubes

Have to admit, as a fellow Go dev, with single binary static compiles, I don't really GET why I need docker... all it seems to offer is an increased workload and complicated build proc

Why not just make QML a media type and a spec that browsers can to implement? Then we can do away with all this HMTL-Page-Is-An-App nonsense

For me, this sums up the current state of front-end web dev. If you have so much JS on page that it affects scrolling, the problem is not the scrolling...

Personally I don't see any of that happening - client-side app development on the web is a chaotic mess with no "official" (whatever that means) way of doing things. Throw into that mix the constant reinvention thats going on (yeah can't wait to see everything get re-invented AGAIN when web-assembly comes along), for what constitute incredibly marginal gains in the UI space (the web UI was already way fast enough 5 years ago without introducing mind-bending paradigms like react).

On top of all that, the very concept of web apps (in my opinion) is fundamentally flawed in that they break the web (fundamentally flawed in a similar way that Flash as a interactive platform was flawed e.g user interaction along a timeline is an inherent conflict).

So personally I expect all the client-side web app stuff to collapse under its own weight at some point. As a example, I've been a web developer for 20 years, and for my own projects at home I don't even bother with web front ends; I use QML and QT and bang out a great UI in a fraction of the time it takes to produce a web UI. It's not worth the hassle anymore, but then I have the luxury of my own projects not having many (any?) users beside myself.

As for back-end, I've actually seen a shift more towards "systems" e.g a set of isolated sub-systems interacting via event busses or queues over HTTP/JSON either as micro-services or something close to that. Then a separate "web front-end" app pull data for output/display, almost as a client to that system. So a cleaner separation of The Real System from Web Application Back-end. And in this space, things seem to becoming much more standardised means of communication between parts, whilst at the same time there is a Cambrian explosion of new tools, languages etc which can be exploited. There is very much an idea that separate sub-systems can be written in languages which can best take advantage of for the problem space.

It's very interesting to see the differences in the way the front-end and back-end communities are approaching progress/innovation.

Anyway, thats my opinion/view of it all. Sorry for the wall of text

"The main intent of introducing proto3 is to clean up protobuf before pushing the language as the foundation of Google's new API platform"

Does anyone know if this means Google's public APIs will be proto3 based? I quite like protobufs.

Wow! Thats a great write up there. Excited to see some action and discussion on this problem.

Actually there has been a bit of movement on this board - they did some initial cost analysis and it came out way to expensive ($1000 a board!) so they are going back to the drawing board.

You can follow along here:

https://twitter.com/9_ties https://twitter.com/IdeinInc

My understanding is it follows the 'plumbing and porcelain' pattern; behind the scenes there are lots of small commands that do one thing and one thing well (the plumbing) and one command that acts as a wrapper over all these commands to keep things simple (the porcelain).

The users in this example are developers; developers are users of APIs.

Article blocks those using an ad-blocker

Isn't this what the "Tick-tock" method of releasing meant to resolve - the first phase, the tick, is all about new, bombastic features, the tock is about removing unused features and tidying up the codebase in general and focusing on performance.

I always thought it was quite a neat compromise - you get the best of both.

Interesting stuff. I was always intrigued by Plan9 (via Go). The same thought had crossed my mind too, that Plan9 may be a great dev environment for Go; apparently the 9p package is excellent.

Anyone had any experience running the RaspberryPi Plan9? It seems like the ideal way to set up a small cluster using some cheap RaspberryPi Zeros as compute, maybe one for file storage and another as a terminal.

I had the same experience; signed up to the mailing list because the articles looked like there was real depth (at last!) really digging deep in the aspects of design. I was also excited by the fact that he appeared to be arguing from a non-modernist design perspective, and as an ardent believer in modernist design, I was excited to have my beliefs challenged.

Unfortunately I found there wasn't much there. Whilst some (most?) of the articles seem to dig into some depth, it's all over shadowed by a negativity that has nothing to back it up, just empty criticism. It's telling that I can't even determining if he's arguing from a pre or post-modernist perspective, or even from a different perspective completely.

I found it all a bit disappointing really. I think he has a point to be made in there somewhere, he certainly begins his arguments from a position that seems tenable, but for the life of me I couldn't prune it from all the dead-wood of negativity.

I really hope the author does dig in and argue a point, because like I said, it certainly feels like he's arguing from a position.

I just hope that after all that, his point isn't "design is art" because he can GTFO :)

I've seen implementations on other systems where this has been solved by placing a vertical bar to the right of the window. The height of this bar represents the total length of the document. Inside this vertical bar is a small bar which represents the current viewing window on the document. The user can "scroll" this small bar to move the current viewport over the large document.

I think I might start overriding the existing methods which users are used to with this method because I've build websites for a couple of years and think I know better than years of UI development by much more experienced people than I.

"Adding a dependency has its cost, but it costs in the (somewhat) distant future. So you're taking some debt now, to repay later at much higher price, except probably you don't see the price at the decision moment and you don't realize it's an instalment when you need to repay part of it."

That is a very nice and succinct summary of dependancies

I suppose you could use it whilst you charge your phone at night?

Exactly! I thought the point was that it was plain text that can be transposed to html. This mime-type designates it as a mark-UP, defeating the whole point!

All very valid points. It would be a shame if the project died. QML and Go just seem to be perfect partners.

There are go bindings that are excellent (https://github.com/go-qml/qml). this, combined with the Google Material style kit (http://github.com/papyros/qml-material) results in very simple, clean apps with all the goodness of go.

For me, the only drawback is not being able to expose a go object as a model, involving a bit of back and forth, but the rest is very very clean.

I still cant for the life of me determine just what it is some of these developers are doing that means the DOM is too slow...

I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"

Really love the idea of embedding the EventSource and image update JavaScript in the SVG doc itself! Keeps the host page clean and tidy! Took me a while to get my head round where the python script was "generating" the svg.

A really clean solution, love it!