Joe8Bit

> Every ten seconds, the most popular keystroke in Twitch chat will be entered into an Arch Linux virtual machine

Seems it's keystroke by keystroke, not command by command.

If someone came up with a way of doing large scale fleet management of Mac devices (software installs, updates, rights management et al) in a vaugley similar way to the way Windows env (eg point and click) they'd make an absolutely fortune.

It's not composable if you only write raw CSS, they're perfectly composable via @extend's and @include's, e.g.

   #login-widget {
      @extends widget();
   }

Best of both world's, the semantic meaning of id's with the composability of classes, plus, the compiler is smart enough to reduce duplicity to it's bare minimum

Yes.

I've hired >50 engineer in the last 12-18 months. They are experienced hires I will grant you, but education is something I barely look at on a resume. In fact, I can't even tell you how many are self taught vs not, but I suspect it's 30%+.

It's a little different for junior engineers, as it can make a difference, but in my experience the only thing you can ask for from any engineer, which is especially true for junior engineers, is: attitude and aptitude.

Awesome, thanks!

Is there a plan to able to run this in a CI environment?

I couldn't disagree more.

I would fit into the 'potential employers' part of your comment, having hired <50 people in the last 12-18 months (and 100's total in my time). If I got a candidates name, and Google'd them (which I always do) and a blog post like this came up: it would have no negative effects on my view of that candidate.

In fact, I would prefer a candidate who knows their limits and is obviously willing to communicate them. I would view a person who would publicly talk about a subject that few others in their position do as someone I would want on my team, as I would view them as more likely to not only push when their workload/lifestyle is becoming unhealthy but would actively help in recognising it in others who maybe wouldn't talk it so readily.

Frankly any organisation that would view something like this as negative is one I would council no one to want to work with.

I think "haphazardly" might be a little harsh, my understanding is that the IO.js core team fully understood the introspection regressions that would occur when bumping V8; but they took the descison that improved runtime performance combined with native support MANY new language features meant the regressions were acceptable. I agree fwiw.

They favoured the many (who would use the new V8's features) over the few (who valued DTrace etc)

I haven't heard any real claims as to IO.js instability, and have been using it production at scale for several months myself.

As far as I understood, removing MDB was an unfortunate side-effect of upgrading V8 to a newer version[0], and while I can see this would be an issue for some people, I would argue that bumping V8 and the performance and core language improvements that come with it is worth it! But I perfectly see you're point.

Also, this is going to be an issue for Node core too eventually, unless they plan to stay on an old version of V8 indefinitely.

Not sure what you're referring to about DTrace issues in IO.JS, could you provide some guidance?

0: https://github.com/iojs/io.js/pull/1023

I understand there a lots of governance/no technical differences, but is there a clear answer as to why Joyent can't use 'fast forward' Node to the current IO.js stable? Are there major discrepancies between the roads the two teams have taken that would necessitate a 'merge' of the two projects?

Been using it production for a couple months now, no issues. We have a reasonable number of IO.js powered microservices, we've seen anecdotally better performance for some use cases but regressions in none, however we've seen SIGNIFICANTLY cleaner code (ES6 yay!) and a much simplified build (no transpilation to ES5!).

Was nervous at first, but now I see no reason to use code Node again.

Figshare[0] has already gotten quite a lot of traction in this space. Full disclosure was started by a friend, but people say very good things.

[0] https://figshare.com

Totally see your point, but it makes me wonder why IBM point to this demo as an example of Watson API usage (and how good it is) when the demo doesn't live up to (anything like?) Watson's true potential.

Strikes me as a little counterproductive from a marketing POV.

I'm not sure if my expectations were overly optimistic, but using the 'Ask Watson' feature in the beer demo gave REALLY disappointingly inaccurate answers to very simple questions about beer.

e.g. "What is beer made from?" resulted in what appeared to just be a link to a wikipedia article on Brewerys. Not sure if this is implementation issues or representative of the underlying Watson API.

Servo is actually in the process of implementing a parallel layout engine[1][2]

1: http://en.wikipedia.org/wiki/Servo_(layout_engine) 2: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

Now is another good time to remind people of projects like Streisand[0], who make setting up censorship avoiding tools simpler that they otherwise would be.

Streisand in particular provides various tools for masking VPN traffic as HTTPS (Stunnel/SSLH et al) that may prove useful during crackdowns like this. As well as setting up things like a tor bridge.

One note, there is currently an issue with the Digital Ocean provisioning, which prevents it from completing initial setup, but I have easily and successfully setup instance on Rackspace and AWS recently.

[0]: https://github.com/jlund/streisand

Agreed, upgraded since the beta and had few issues, and only then on beta releases that have since been fixed. Not sure how constructive this comment is, but thought it was worth seconding your experience.

Does anyone know what implications this has on licensing of the fonts? I assume there's a restricted redistribution clause for some of the fonts

Seems to work fine for me in the three ways I tried, via Virgin Fibre (from London), EE 4G and O2 4G.

On a slightly tangential note, after having used Mou for a while I've recently moved to Macdown[0] for Markdown editing on the Mac after Mou seemed to be abandoned, plus, it's open source!

I mention it as the live previews in both those apps are the real winners for me, and having something like that in my regular text editor would be awesome. Not such a fan of the browser based previews, but I'll give it a go!

[0] http://macdown.uranusjr.com/

The semantics of the "different" origin escaping will be interesting, in that they talk about about rich text editing and the clipboard API's usefulness there, but isn't removing the ability to copy/paste HTML 'formatted' text from another origin a part of that use case?

If the SASS compiler wasn't smart enough to deduplicate several references to a mixin it would unquestionably mean redundant properties and more weight in the compiled CSS, but it wouldn't be any less efficient from a page paint POV.

There's a completely valid argument that any "improvements" in the above sense are outweighed by the extra time in downloading and parsing a larger cold-cached CSS file, but in my case I am happy to rely on the browser cache and the compiler to be smart (and maybe sacrifice a small amount of resulting CSS weight if it's not) resulting in "cleaner", more semantic HTML (and arguably CSS).

In terms of the second login widget, you're absolutely right, my implementation would fall down, but then it would be a VERY simple refactor. However having n of something on a page would have a semantically different meaning than my case, so therefore classes are indeed the right specificity method!

I would argue about cleaner code, in my view doing something like:

    // HTML
    <div id="myLoginWidget">...</div>
    
    // SCSS
    #myLoginWidget {
      @extends #baseWidget;
      @extends #somethingElse;
      @include rounded-cornders(0.5rem);
      background: darken($base-blue, 20%);
      ...
    }

Is 'cleaner' than:

    // HTML
    <div class="baseWidget somethingElse small-rounded-corners dark-blue-bg">...</div>

    // SCSS
    .baseWidget { ... }
    .somethingElse { ... }
    .small-rounded-corners { ... }
    .dark-blue-bg { ... }

It achieves the same reusability (in code) without polluting the content (HTML) with the presentation (CSS).

I have to admit to not feeling too strongly either way about this, but the argument I would have against the 'never use IDs in CSS selectors' is purely a semantic one.

An ID, by design, semantically references a single thing. This has important meaning when making HTML (amd CSS) readable and parseable. Now, I'm not necessarily saying this is a 'winning' argument, but throwing away a useful tool for declaring semantic meaning for hand wave'y arguments about 'britality' feels like overkill.

GHE is (minus the things coming in this v2) the same as using public Github, so in my view is the superior experience to using GL (in most ways I can think of).

The issue I have ALWAYS had with GHE isn't with GHE itself but with how organisations use it, there are usually dozens of organisations that make little sense and 1000's of repos that are often empty or abandoned. It becomes a black box of repos that no one really knows the ends of.

The real improvements GitHub could make to GHE is improve the discoverability experience, it's UI/UX is inherited from public Github where people work in small(ish) groups on single projects within individual orgs. This, for me, is not the paradigm people employ in GHE.

I like this idea (and backed it!) but I'd have liked if the fact it was going to be a commercial font was more apparent on the KickStarter page, as it feels a bit buried at the moment. I doubt this was deliberate, but I can say personally having the 'Font Awesome' brand being used so prominently made me think it was going to be open source.

Looking at the debates there are in local governments in the US, it's interesting to look at how Uber has been received in London.

In London, we've had a setup for licensing 'mini-cabs' for almost a decade (and they've been around for far longer than that). In essence, they are all registered and regulated by a central authority, in a similar (but much less strict) way to London's famous black cabs. The difference being that mini-cabs are normal cars, that must be prebooked.

In that sense Uber fit right in, they're just another (one of 100's, if not 1000's) mini-cab providers. So for us in London, Uber hasn't really been revelatory at all except in the app driven aspects of their service (which is great).

There's always been a tension between liveried cabs and these 'mini-cabs' in London, and that's something that's been really interesting to see played out in different markets in the US. Especially when it's tied to the more prevalent laissez-faire attitude that the US has to market regulation.

I've been thinking about this recently, as like others in this thread I too have't used it in a while, but I think it's less indicative of the quality of the premise behind App.net (pay = no ads + privacy) than how little I notice Twitter ads and consequently how little they alienate me onto another platform.

While I disagree with the comment you're responding to, and agree with yours, there are some interesting problems doing resource heavy operations in ML/NLP in an environment like Node that's inherently single threaded.

I'm actually adding multi-threading to classifier training in node-natural as we speak [0] so it's something I'm recently familiar with. Multi-threading in JS isn't new or particularly exciting (even less so is multithreading in ML/NLP applications) but the marriage of the two has led to a few interesting problems in JS's asynchronous/event based view of the world!

[0]: https://github.com/NaturalNode/natural/issues/124

--

Edited for clarity

If you're looking for more on this, or some general purpose JS NLP you'd do worse than to checkout node-natural[0]

[0]: https://github.com/NaturalNode/natural